Version: (using KDE KDE 3.5.1) Installed from: Debian testing/unstable Packages Show numbers of songs for each item in collection browser, in a second column. I posted the idea here: http://amarok.kde.org/component/option,com_simpleboard/Itemid,57/func,view/id,1655/catid,9/ and the patch on the mailing list some weeks ago. Seems it got lost there. cf. http://comments.gmane.org/gmane.comp.kde.amarok.devel/4748 Please commit.
Created attachment 15042 [details] collectionbrowser-numbers.patch
Could you attach a screenshot?
Created attachment 15055 [details] yup, this one sorted by genre totals
this patch is harmful... correct me if i'm wrong, but - qb.addReturnValue( q_cat1, QueryBuilder::valName ); + qb.addReturnFunctionValue( QueryBuilder::funcCount, QueryBuilder::tabSong, QueryBuilder::valURL ); this looks like you're always counting no matter if the column is visible or hidden. should only happen if the column is visible. like you seem to do above for some other case: + if( columns() > 1 ) { as mentioned, just a quick look at the source and please correct me if i'm wrong. cheers, muesli
this is only for one single query (compilation count), not for all the collection entries. So it shouldn't do any harm at all. (Logically, you're right, I could also have checked if columns > 1 there, but this version just does the same thing as before, plus giving me the information I need (compilation count).. so imho I get nicer code which is not really slower)
ok, since the report is still open, I'll write a few words, why I think this feature is beneficial. Basically, it allows completely new (and statistically interesting) views to your collection: - Depending on the grouping method, you can immediately see how your collection divides in terms of genres, years or artists, thus probably finding out things you didn't know before. After all... Rediscover Your Music? :-) - Grouped by "Artist - Album" (probably the most common case), it reveals relevant information for those people who don't have full albums only (probably the most common case again, I'd guess). At first level, it's much easier to pick out artists that "form the core of your collection". For example, I have a lot of artists (maybe 50%) with only one or two songs, and they appeared undistinguishable from the ones I have several albums of. At second level accordingly, it's convenient to be able to distinguish the complete albums from the non-complete albums or singles. Having said that, unfortunately it seems that my patch is unacceptably slow when used with SQLite. (I can't test that currently). I'm using it contentedly with MySQL and quite a large collection though. And I really don't want to miss this feature anymore. From an aesthetic point of view, I don't find it disturbing - quite the contrary. Wouldn't it be an option to add this feature, BUT disable the column by default - for now? (Until maybe someone (or myself) finds a better performing solution.) Then, it should probably show a little warning when switched on for the first time, and SQLite is used.
Created attachment 17511 [details] screenshot, small visual improvements just a little update, well, sadly i'm not actively using this feature anymore myself, since some change in Amarok (a few months ago, maybe the dividers?) has caused it to be 10-20 times slower than before, so it is now unusable even with MySQL (except when using genre- or year-grouping)... i can make a new patch though, if someone still wants to check it out or use it for building a better solution...
mm. seems to be a nice functionality. if i understand correctly, amarok currently does not query subitems for performance reasons, so this column would introduce some slowdown - but if it only happens when the column is enabled, that would be fine. i could test the patch, if you could find the reason for massive slowdown :)
I'm really looking forward to this functionallity; also on Device browsing tab...
tbh, i don't really like the idea of this feature, seems to add a lot of clutter and interface distractions. Why would you need to know the number of children each tree item has? And why would you need to know regularly?
I think it would be unobstrusive, and very helpfull when browsing through collection to decide quickly which artists/albums add to playlist in order to reach a certain volume of songs. Actually all items in the collection browser have the same "relevance", no matter de number of songs they have inside. Maybe another option could be a pattern of colors, boldness or other thing that somewhat indicates the "weight" of an item. I'm always talking about the collection (and device) browser. I don't know if i explain myself very well, i'm not english natural speaker :)
I agree with Seb, this feature seems pointless to me. I don't think we will implement it, so I'm closing the report.