extragear/multimedia/amarok/src/browsers

[Seb Ruiz]

2009/5/4 Dan Meltzer <parallelgrapefruit at gmail.com>:
> On Sun, May 3, 2009 at 6:58 PM, Seb Ruiz <ruiz at kde.org> wrote:
>> 2009/5/4 Sven Krohlas <sven at asbest-online.de>:
>>>
>>>         actions.append( m_loadAction );
>>> -
>>> -        if( m_queueAction == 0 )
>>> -        {
>>> -            m_queueAction = new PopupDropperAction( The::svgHandler()->getRenderer( "amarok/images/pud_items.svg" ), "queue", KIcon( "media-track-queue-amarok" ), i18n( "&Queue" ), this );
>>> -            connect( m_queueAction, SIGNAL( triggered() ), this, SLOT( slotQueueChildTracks() ) );
>>> -        }
>>> -
>>> -        actions.append( m_queueAction );
>>>     }
>>>
>>
>> This is a regression, because it not only removes the queue action
>> from the PUD, but also from the context menu in the collection
>> browser.
>
> I'd argue that this is perfectly acceptable, myself.  I see the queue
> as changing the order of the playlist (without changing the order of
> the playlist), if it hasn't reached the playlist yet then it doesn't
> make much sense to modify it in this way.  The exception being random
> playback, but I feel like we could fix that in a different way...

Yep, I use queue tracks in two circumstances: when playing in random
mode, and when using dynamic playlists. In both cases, I don't want to
have to add to the playlist, and then queue. I want to do both in one
operation.

>
> Dan,
>>
>>
>> --
>> Seb Ruiz
>>
>> http://www.sebruiz.net/
>> http://amarok.kde.org/
>> _______________________________________________
>> Amarok-devel mailing list
>> Amarok-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/amarok-devel
>>
>



-- 
Seb Ruiz

http://www.sebruiz.net/
http://amarok.kde.org/