Re: [amarok] src: avoid code duplication in user playlists; fixes to playlist browser

2012-04-11 Thread Matěj Laitl
On 11. 4. 2012 Bart Cerneels wrote: > Big one, took a while to understand everything that was happening. > Perhaps splitting up the code deduplication and inline rename would > have been a better option. You're right, sorry about that. My commit-making part of the brain was having a walk or somet

Re: [amarok] src/browsers/playlistbrowser: Playlist browser: normalize connect() calls

2012-04-11 Thread Matěj Laitl
On 11. 4. 2012 Bart Cerneels wrote: > I think the style for function statements should be applied to the > contents of SIGNAL/SLOT macro's as well. i.e. space after and before > the parentheses. I don't use that style for macros since they are not > functions, with the capitals it's clear they aren

Re: [amarok] src/browsers/playlistbrowser: Playlist browser: normalize connect() calls

2012-04-11 Thread Bart Cerneels
I think the style for function statements should be applied to the contents of SIGNAL/SLOT macro's as well. i.e. space after and before the parentheses. I don't use that style for macros since they are not functions, with the capitals it's clear they aren't. Probably best to stick to the style. S

Re: [amarok] /: distinguish between mp4, m4a, m4v types in Amarok::FileType

2012-04-11 Thread Bart Cerneels
On Wed, Apr 11, 2012 at 11:10, Matěj Laitl wrote: > I'm running this through review board as there seems no general > agreement on Meta::Track:type() semantics. (Speaking of which, I'd be > most satisfied if it returned (the most specific) mime-type represented > using dedicated class that would s

Re: Review Request: Some changes to the handling of cover art reading and writing

2012-04-11 Thread Matěj Laitl
> On April 10, 2012, 4:57 p.m., Matěj Laitl wrote: > > I agree that current hard-coded value of 200px is a bit suboptimal. But I > > doubt there is a significant group of users that makes use of multiple > > per-file covers. When I order Amarok to replace track cover, I want Amarok > > to "mak

Re: Review Request: Some changes to the handling of cover art reading and writing

2012-04-11 Thread Daniel Faust
> On April 10, 2012, 4:57 p.m., Matěj Laitl wrote: > > I agree that current hard-coded value of 200px is a bit suboptimal. But I > > doubt there is a significant group of users that makes use of multiple > > per-file covers. When I order Amarok to replace track cover, I want Amarok > > to "mak

Re: Review Request: Some changes to the handling of cover art reading and writing

2012-04-11 Thread Daniel Faust
> On April 10, 2012, 1:55 p.m., Bart Cerneels wrote: > > Overall I think this is a lot of config for a pretty esoteric feature. It's > > nice to have embedded covers, but can't we implement a default that works > > for the 98%? The problem why I implemented the 'overwrite mode' option was that