Skip to content

Rearrangable Clocks

Description

Clocks are made to be draggable based on this sample project from Qt. By tapping and holding on a clock, the user can drag the clocks to reorder the list.

The world clocks are now hidden behind a DelegateModel, as this model allows the items to be reordered without affecting the underlying data model. This is necessary because if the data model emits a reset signal the clock will be dropped from its drag action so it would only be possible to move one space at a time whereas with DelegateModel the items can be moved arbitrarily many spaces back and forth.

The user's clock order is stored in the database as a QMap (mapping desired visual position to city name) and restored on app launch. I modified the GenericTimeZoneModel to redirect the data method to a different row based on the user's ordering. This way, internally, the clocks are still stored alphabetically, but they are visualized in the ListView in the order specified by the user.

When adding or deleting clocks, the internal ordering is updated to account for the additional or removed clocks. I also added a method for switching from the visual index to the internal index. This might turn out to be unnecessary in further testing.

Problems

Since the GenericTimeZoneModel isn't visible from WorldCityList, I didn't find a way to pass the added city to the data model. This means that whenever the results are updated, we have to explicitly search the ordering to determine whether the city existed before. This adds O(n) complexity to an otherwise constant time function. This could easily be avoided if there were a way to call a function in the data model from the city list to add the missing ordering entry.

As mentioned earlier, the conversion between internal and visual index might not be necessary. I will need to test this further, but because of the reordering of the items, index in the list view delegate shouldn't refer to the internal index after relaunching the application: index refers to the index of the item without any reordering from the DelegateModel, but if the app is launched after the clocks have already been reordered, these indices will not match the internal ones because the user will see the clocks in their desired order and not the internal, alphabetized order. I omitted the conversion for deleting the last element since in this case the visual, actual, and internal index will all always be 0.

Related Issue

Closes #141.

Edited by Alessandro Vinciguerra

Merge request reports