Source refactoring

[asermax]

Well, as I and foss planned, it's time to start doing some refactoring on the source to correctly divide the functionality in multiple specialized widgets or objects (there may be some logic without a prpper UI) to achieve a better modularized code, easier to modify and extend.

I though of using this post to put down some guidelines about how we should work on it:

• There will be a long term branch (source-refactoring, which I already created) which will be the target for all the coding refactoring.
• The source-refactoring branch should not be merged with master (or the other way around) without a real reason. To be clearer, merging should only happen if there is a mayor bugfix in any of the branches. Merging after minor bugfixes or enhancements will only pollute the commit tree and make it difficult to read/find/revert commits and will make the refactoring harder.
• There should be no more UI enhancements on the master branch. If there is a need to modify or add a new UI element, it should be done in a branch of the `source-refactoring`` branch and should be merged to the same branch once done.
• At the same time, bugs or enhancements unrelated to the UI (or to be more exact, to the UI related elements of the coverart_browser_source module) should be done on the master branch (if it's a minor fix) or in branch created from it.

Finally, we should use this post to notify of changes and discuss about different aspects of the refactoring.

For starters, I did a clean up of the widgets module, removed some unneded code and moved all the logic related to the specialized buttons there. Next I think I will tackle the main cover view widget if it's posible (if it doesn't break everything).

[asermax]

I was going to post an idea for the organization of the code and ask what other ideas where out there to define the new structure and the API for the views, but I see that you started working on that already on the master branch, so I guess I will let you to it then.

It've been really hard for me to find time to dedicate to this and the other plugins I mantain, and it seems like it will still be like that for the rest of the year (school, job, dumb priorities xD) so I probably won't contribute much, pretty much like what I've been doing so far. I will try to fix whatever I can and step in whenever I have time, but I don't promise anything :< Also feel free to ask for help on any specific issue, I do have some time to read and answer my emails!

[fossfreedom]

hey - no worries - but I would like to take you up on your read and answer emails... :)

I've been looking at how best to get the list of albums and their coverart-file locations so that this can feed into the coverflow.

I suppose one way would be to add a new column to the albummanager model holding the file location which we use anyway to create the pixbuf (load_cover method on CoverManager).

What I'm fuzzy on though is how to retrieve this info whenever the filtermodel changes due to the user searching/changing genres etc - is this the "album-updated" signal in the AlbumShowingPolicy - or possibly the "visual-updated" signal? Any pseudo code would be useful ...

[asermax]

For the cover paths: iirc, the Cover saves the file path in it's original attribute. It does so to handle the resizing and adding/removing shadows, since it needs the raw image to avoid ruining the image quality. The only exception to this are the covers that are added on the current session, since the signal fired when the cover is added sends the already created Pixbuf instead of the path, and that's what get saved on the original attr. That can be easily changed to make sure you always save the path sowhere on the Cover instance. That is what makes more sense in my opinion. Saving it on the tree model isn't that necesary, since you never show the path on the views.

For the model changes: the showing policy doesn't take care nor it listen for signals on filtering, it's supossed to manage how each album information is updated on screen when an album gets updated. For example, a loading cover can appear like a waiting icon, and when the album gets it's cover loaded, the policy decides to either update the album cover on the view (by replacing the loading icon for the actual cover) or it can decide to not change anything since the album isn't on the viewport. Well, at least that was the original idea, but never got to it since it was working fine without that optimization.

To listen for filter changes, you can either listen to the filter_changed on the AlbumModel or listen to some of the signals defined for TreeModel or ListStore on the filtered_model. I recommend the first option, as it currently stands, the filter_changed signal forces the model to filter itself first, and once it's filtered, the other callbacks are called, so you can safely assume that when you recieve the signal, the filtered_model is already filtered by the user criteria.