implements the option to sort ascending or descending for all views except the album view.
currently there is only one possibility to sort for each view, e.g. album name for the all album view
mgallien |
Elisa |
implements the option to sort ascending or descending for all views except the album view.
currently there is only one possibility to sort for each view, e.g. album name for the all album view
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
Looks like we'll ideally need more icons, because that one currently implies alphabetical sorting with the A and the Z in it. Also those icons don't exactly localize well...
There are alphabetically sorted, it's just in the all tracks view that the track number is additionally taken into account. But yes, localization is a valid point. I could just use an arrow up and down instead
FWIW, Here are my votes for sensible defaults for the other views
Also, ascending and descending sorting are mutually exclusive, and one is always used. So I would recommend making the buttons into toggles rather than pushbuttons, and have one always be visually in the checked state.
Thanks Alex for your work.
It works fine. This is nice.
Could you try to have one single button with three states ?
Another solution would be to follow dolphin or cantata and have a menu with the choice of data to sort. The button would just indicate if it is ascending or descending.
A single multi-mode button would be nice, yes, but what does "unsorted" actually mean for a collection of music? A random order?
unsorted would be the order in which the tracks were added to the library, which is not useful in my opinion. I would chose to default to ascending.
Choice of data to sort is definitely on my list, but one step at a time :) Should be fairly easy to implement it for the artist and album views, and a little bit more complicated for the all tracks view.
implementation with a single toggle button
I sticked to the current icon until we get a better one. An arrow alone is also not very meaningful
Looks really good. I am reviewing the track sort method because through testing, things are not clear to me.
The first time I press the sort button there is a noticeable delay during which the application is blocked.
I would really prefer to have another default for the tracks proxy model.
src/models/alltracksproxymodel.cpp | ||
---|---|---|
76โ98 | The track sorting is not easy to understand for me. If we add a way to choose the way to sort, we may no longer need a good default but in the meantime, I would suggest to sort by title then album and then artist. Currently, without looking at the code I did not understood the sort being used. |
I haven't experienced a delay, but I think you have a larger library.
That actually points out to a major flaw with the current design. Since the sorting is done in the proxy model, it will always be blocking the ui thread. Reading some sources on the internet, this cannot be changed.
Most recommend to do the sorting in the "real" model anyways, and with D11167 this would then be done in a non-blocking way. Is it okay to port the sorting to the real models for this patch and merge? That would still impose blocking currently. Or do you prefer to postpone this completely until the models are moved to a different thread?
src/models/alltracksproxymodel.cpp | ||
---|---|---|
76โ98 | Think of it as a prioritized sorting with 4 columns, e.g. it is first sorted by artist, then by album, then by track. |
Well, I believe that your patch is already a very big improvement. Let's integrate it and we can always improve later without impact on the interface. This is filling a big gap and people are waiting for it.
Most recommend to do the sorting in the "real" model anyways, and with D11167 this would then be done in a non-blocking way. Is it okay to port the sorting to the real models for this patch and merge? That would still impose blocking currently. Or do you prefer to postpone this completely until the models are moved to a different thread?
I am still not sure that the added complexity of D11167 is worth it. Let's not block progress because of it.