Request: Add a year sort option

[jrbastien]

This one is of a lesser importance than #77 but when I browse my jazz music, the albums ranges from the 30's to today and the style of jazz changes quite a bit.

So I usually sort them by year.

[fossfreedom]

Similar comment as #77

The sort by options need to be carefully thought through

Possibly we should combine the two ascending/descending buttons as one button - pictorially have an "up arrow" for ascending, "down arrow" for "descending".

Then have a "year" sort button added next to "album" & "artist" - this will be similarly a radio button.

i.e. click "year" and it will sort the albums by year. Click "artist" and sort by artist. Click "album" and sort by "album name". You wouldnt be able to sort by first by year and then by either album or artist.

Thats the easiest visual view I can think of.

If we want a "sort by album/artist/year" in different combinations, then we need to think carefully how visually this should look.

[fossfreedom]

@jrbastien

Ok - in rhythmbox an album doesnt have a year - it is only tracks that have "years"

Thus to sort by an "album year" needs some-sort of calculation.

For example - if all the tracks in the album has one year - that is the album year.

if some tracks have different years the album year should be taken from the track that is newest?

If none of the tracks have a year i.e. "Unknown" - then the album year should be "this year"?

Thoughts?

[jrbastien]

My thoughts:

• How does it works for genres? Genre can be set by track as well.
• It is unlikely that you will have an album with tracks of different years. All the compilation albums that I have purchased legally have the release date as the track years. The ones I ripped of my CDs also have a single date since you have to manually edit all the tracks to set a different year.
• But if happens, my preference would be to take the oldest track year as the album year.
• If no years are defined, yes taking the current year is acceptable. Either this or consider them to be the year 0. People who care about this ordering will see the problem right away and will fix the track tags.

[fossfreedom]

Its a similar issue - every track has a genre - an album doesnt have a genre either.

The majority of albums have just one track and one year set for all tracks - so its easy and obvious.

I've got a few compilation albums where tracks have different years and/or genres as well.

Currently the plugin says when filtering my genre in the drop-down "if an album has a track with the chosen genre show that album".

ok - oldest track year will be in the calculation. Year 0 seems like a good idea as well.

[fossfreedom]

ok - have now added an optional year sort option (enabled through the plugin preferences)

I havent yet figured out how to get the album view to refresh if a track/tracks of an album has/have their year value changed.

The sort option though should work.

[jrbastien]

Thank you for this. This is works fine. I see the issue with the refresh. The only way to have it sorted properly again is to exit RB and go back in.

[fossfreedom]

@asermax - I hope the exams are progressing well. If you have some time, any thoughts on the best way to get the coverview to refresh after changing track years or ratings?

I've connected the changes in AlbumLoader and I can see the values are being updated correctly on the corresponding Albums.

The emit is issuing an "album-modified" signal and the corresponding function in coverart-browser-source is being run.

What I'm wary of though is that multiple album-modified signals could be issued which would fire for each track change i.e. set 12 tracks in an album to have an updated Year or Rating would fire 12 album-modified signals.

[asermax]

Hi there! This end of year is being more than complicated for me :/ not only exams but a lot of projects to present... I don't think I'll be free to do anything fun for a couple of weeks more u_u

Anyway, I still follow the changes you are making, and I can take a break to try to help you out d: For what I tested so far from the changes you made to implement this feature, here are some insights:

• The property changed when you update the entrie's year is actually the DATE property according to the debug info, so the _entry_album_year_modified method is not being called, and the album-modified signal is not being thrown.
• If you don't want the signal to be thrown multiple times for the same album if the value hasn't actually changed (e.g. multiple entries got it's year changed, the first one updates the Album's year, the others don't do anything), you could add a return value to the entry_year_modified method to indicate if the value has indeed changed. If it did, then you emit the signal.
• The callback on the coverart source doesn't deal with reordering, since it wasn't it's purpouse when I initially implemented it. You could either change it's behavior adding the code to force a reordering (resetting the ordering function I guess), but I think it would be pretty expensive and unnecesary (since it forces the reordering in the whole model). I think the faster way is to remove and readd the album to the model. That would force the model to reposition the album in it's correct position, given the ordering function set on the model.

Hope this helps you finishing with this enhancement :] let me know if there's something else I can help with.

[fossfreedom]

@asermax - yes you are correct about removing and readding the album - this works well... with one exception.

The iconview selections are lost thus losing what you see in the entry-view.

First thought was to emit a new signal just before removing the album. This signal saves the currently selected albums.

The second signal emit after readding the album. The intention was to search somehow in the coverview for the last selected album(s) and reselect them.

Was going to use iconview.select_path - this uses a treepath parameter. Question I cant figure out - matching the selected album with the cover-view tree-model (iconview.get_model) is easy enough - how do you get from the the matching position in the tree-model to find the equivalent treepath so you can then run the function iconview.select_path.

Any ideas?

http://www.roojs.org/seed/gir-1.2-gtk-3.0/gjs/Gtk.IconView.html

[asermax]

I don't quite understand your question :T

But if it's what I think it's, you want to get the tree path for the album right? Well, we are saving the treeiter for each album (so it can later update itself on the model), and the GtkTreeModel interface (which GtkListStore implements) provides a pair of methods to go from treeiter to treepath and the other way around. You can find the one you need here. Let me know if that's what you needed or if I interpreted wrong xD

[fossfreedom]

Absolutely correct - thanks. Thats what I needed.