Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crates should remember their own sort method #9606

Open
mixxxbot opened this issue Aug 23, 2022 · 3 comments
Open

crates should remember their own sort method #9606

mixxxbot opened this issue Aug 23, 2022 · 3 comments
Labels

Comments

@mixxxbot
Copy link
Collaborator

Reported by: ywwg
Date: 2019-03-02T15:51:12Z
Status: In Progress
Importance: Wishlist
Launchpad Issue: lp1818342


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.

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2019-03-03T18:50:31Z


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.
  • 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 "prepareLoadTrackModel" or something.

Suggestions welcome.

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2019-03-17T12:02:53Z


WIP: #2046

@mixxxbot
Copy link
Collaborator Author

Commented by: ronso0
Date: 2021-01-11T23:37:59Z


superseded by #3063

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant