extragear/multimedia/amarok/src/playlist

[Teo Mrnjavac]

On Thu, Oct 30, 2008 at 2:29 PM, Casey Link <unnamedrambler at gmail.com> wrote:
> On Thu, Oct 30, 2008 at 8:45 AM, Lydia Pintscher <lydia at kde.org> wrote:
>> On Thu, Oct 30, 2008 at 1:34 PM, Nikolaj Hald Nielsen
>> <nhnfreespirit at gmail.com> wrote:
>>> No, the current code ( still using pointer comparisons ) does not
>>> group together albums that should not be grouped, but the amount of
>>> things that should be, but are not, is considerable. Right now I am
>>> merely going on what _feels_ the least broken, and to me that is
>>> clearly using the album names. Even if tracks from similarly named (
>>> but distinct ) albums are incorrectly grouped together ( something
>>> that can be reduced significantly by checking the album name if
>>> available ), it will still be immediately clear to the user _why_ this
>>> happens ( hey, they have the same album name.. that is a bit silly but
>>> sort of make sense. i.e. minor bug ) , as opposed to now where the
>>> playlist feels broken as it does not group a bunch of cases that, from
>>> a user perspective, should obviously be grouped ( Oh, adding this book
>>> from librivox does not group the tracks together, even though they all
>>> have the same album name. Hmm, this album I just added from the file
>>> browser is not grouped either... That looks like a big bug in the
>>> playlist  ).
>>>
>>> As I have said many times, I am more than willing to do a popper fix,
>>> post 2.0.0.
>>>
>>> Also, I am not sure I agree that grouping is a non essential feature
>>> with the new playlist design.
>>>
>>> - Nikolaj
>>>
>>> ps. please remember to hit reply to all ;-)
>>
>> ++ on going the way that annoys the user least for now.
>> Also we have to keep in mind that the playlist takes up a lot of
>> vertical space. So the solution that groups more tracks together
>> should be preferred especially since those that are grouped together
>> incorrectly are rather obvious to the user as Nikolaj said.
>>
>>
>> Cheers
>> Lydia
>>
>>
>
> On Thu, Oct 30, 2008 at 8:45 AM, Lydia Pintscher <lydia at kde.org> wrote:
>> On Thu, Oct 30, 2008 at 1:34 PM, Nikolaj Hald Nielsen
>> <nhnfreespirit at gmail.com> wrote:
>>> No, the current code ( still using pointer comparisons ) does not
>>> group together albums that should not be grouped, but the amount of
>>> things that should be, but are not, is considerable. Right now I am
>>> merely going on what _feels_ the least broken, and to me that is
>>> clearly using the album names. Even if tracks from similarly named (
>>> but distinct ) albums are incorrectly grouped together ( something
>>> that can be reduced significantly by checking the album name if
>>> available ), it will still be immediately clear to the user _why_ this
>>> happens ( hey, they have the same album name.. that is a bit silly but
>>> sort of make sense. i.e. minor bug ) , as opposed to now where the
>>> playlist feels broken as it does not group a bunch of cases that, from
>>> a user perspective, should obviously be grouped ( Oh, adding this book
>>> from librivox does not group the tracks together, even though they all
>>> have the same album name. Hmm, this album I just added from the file
>>> browser is not grouped either... That looks like a big bug in the
>>> playlist  ).
>>>
>>> As I have said many times, I am more than willing to do a popper fix,
>>> post 2.0.0.
>>>
>>> Also, I am not sure I agree that grouping is a non essential feature
>>> with the new playlist design.
>>>
>>> - Nikolaj
>>>
>>> ps. please remember to hit reply to all ;-)
>>
>> ++ on going the way that annoys the user least for now.
>> Also we have to keep in mind that the playlist takes up a lot of
>> vertical space. So the solution that groups more tracks together
>> should be preferred especially since those that are grouped together
>> incorrectly are rather obvious to the user as Nikolaj said.
>>
>>
>> Cheers
>> Lydia
>>
>
> Why are we so concerned about a temporary fix? This is a crazy
> important bug that needs to be fixed. Obviously neither of the
> proposed solutions , as they stand, are tenable in the long term.
> Let's brainstorm and fix this issue for good, instead of pushing it
> back to a later date when we'll have to dredge up this topic again and
> repeat all the old arguments.
>
> Just because we have a tagging coming up, and just because we have a
> major release coming up doesn't mean we should start taking the easy
> way out.
>
> "all, i think our priority is to give the best experience to our
> users" <--- exactly and a temp fix that isn't any better than the
> current code isn't useful.
>
> Now, as for actual solutions. Can we tweak all the Meta
> implementations so they use the same album ptr? Each Meta
> implementation has a Collection and we store albums in it, so why
> can't we attempt to retrieve an album by X artist when we are creating
> new tracks. If one doesn't exist, then we create it.
>
I agree that often there's nothing more permanent than a temporary
workaround and the proper solution should be at the top of our TODO
list but we are already behind schedule so let's focus on pushing
something usable out and then take our time for 2.1.