crates should remember their own sort method
Bug #1818342 reported by
Owen Williams
This bug affects 3 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mixxx |
In Progress
|
Wishlist
|
Owen Williams |
Bug Description
Different crates serve different purposes, so I'd like to be able to have each crate remember their own sort order. For instance, my "pop" crate should be sorted by bpm, but my House crate should be sorted by comment field.
By default, a crate would use whatever the main library sorting method is. But if I change the sort order, mixxx should remember it.
As a point of reference, the Evolution email program does this for individual email folders and it's really nice.
Changed in mixxx: | |
importance: | Undecided → Wishlist |
Changed in mixxx: | |
status: | New → Confirmed |
Changed in mixxx: | |
milestone: | 2.3.0 → 2.3.1 |
Changed in mixxx: | |
milestone: | 2.3.1 → none |
To post a comment you must log in.
OK so this is tricky because of the library view header state.
In general, every time the user chooses a sort column we can have the model save the new sql sort order.
When the user clicks on a crate, these things happen:
1. The crate model is told to update to the new crate. We've already saved any changes to the sort order so that's good, and we can load the sort ordering for the new crate.
2. The table view gets the showtrackmodel signal -- in this case it's the same object.
3. We can load the persisted state for the header view
The problem is, when do we *save* the header view state? The correct answer is in step 3, as part of the loadTrackModel function: that's when we have access to the header in the latest state. But we don't know what the *old* crate id is so that we can persist it to the database in the right place. We've already updated the model, so that information is blown away.
The two main options I can think of are:
* save the header state after every change to it. Unfortunately there are a lot of ways the headers can change, including size, so this doesn't seem practical. ckModel" or something.
* Introducing a new signal like "saveHeaderState" that the cratefeature can emit as a step 0, so that the header state is saved to the correct crate before we change the model. Maybe the call can be more generic, like "prepareLoadTra
Suggestions welcome.