Standardizing Context Menu Actions

[Alejandro Wainzinger]

In the case of the CollectionTreeView, it can generate a TrackList
from list of selected items, using a querymaker.  The problem is that
if I run the querymaker, I believe it runs async and so it could be
that the context menu is displayed, the user clicks an action, and the
slot is called before the querymaker finishes (i.e. race condition).

What would be gained from passing the QM to the CollectionCapability
instance?  Running the QM from within the CC instance amounts to the
same thing since it runs async, and the CC instance is deleted right
after the actions list is returned, after which the context menu is
generated.

One of the odd ideas I played with was forcing the user of
CollectionCapability to pass itself in as a parameter to the
constructor, and to provide a particular signal for when its TrackList
is ready, which then calls the appropriate slot in the Collection
associated with the action.  First, I'm not sure the right sequence of
signal/slot connections to make this possible, and second this is an
ugly solution as it requires the user object to know about the insides
of CollectionCapability.

On Sat, Nov 8, 2008 at 12:14 AM, Maximilian Kossick
<maximilian.kossick at googlemail.com> wrote:
> don't you have (or can get) the list of tracks (or at least a
> querymaker instanc that will return the tracks) when you call
> getActions on the CollectionCapability? how about passing the track
> list or the querymaker to the CollectionCapability instance, and let
> it pass the list or querymaker to all the actions.
>
> On Sat, Nov 8, 2008 at 8:50 AM, Alejandro Wainzinger
> <aikawarazuni at gmail.com> wrote:
>> Ok so I've hit a wall in making this work.  In order to give
>> Collection class the ability to use Capability things, I've taken the
>> pieces of MetaBase which create the interface for that, and stuffed
>> them into another class, from which Collection now inherits.  Maybe
>> not the most elegant, but works for now.
>>
>> I've created a CollectionCapability, whose subclasses generate a QList
>> of PopupDropperAction* to be inserted into for instance the context
>> menu, much like CustomActionsCapability does for a single item in the
>> CollectionTreeView's context menu.  In the CollectionCapability
>> constructor, I connect the Actions' signals to the appropriate
>> Collection's slots (e.g. deleteAction goes to deleteTracks).  The
>> problem is in getting the Meta::TrackList of tracks to act on, to the
>> Collection before the Collection's slot is executed.  After all, you
>> can't delete a list of tracks before you have the list available.
>>
>> I'm thinking some sequence of signal/slot calls, but I've tried
>> several designs and none of them work out.  Ideas please =)
>>
>> On Mon, Nov 3, 2008 at 9:04 AM, Alejandro Wainzinger
>> <aikawarazuni at gmail.com> wrote:
>>> I've already begun working on this now, just to have the patches ready
>>> to go (plus so that I can have my delete tracks feature now, not
>>> later).
>>>
>>> On Mon, Nov 3, 2008 at 7:41 AM, Jeff Mitchell <kde-dev at emailgoeshere.com> wrote:
>>>> Nikolaj Hald Nielsen wrote:
>>>>> I definitely think this is something we should target for 2.0.1. As
>>>>> soon as possible without delaying our 2.0.0 release.
>>>>>
>>>>> I agree that it is a major annoyance in some cases, but I dont think
>>>>> it is a show stopper, especially if we fix it quickly.
>>>>
>>>> I was about to say this exact thing.  We've always had the "release
>>>> early, release often" approach.  Why not start working on these things
>>>> as soon as we have our code freeze for 2.0, and release 2.0.1 soon after?
>>>>
>>>> There's an added benefit to this: if we keep adding these major, nice
>>>> features in regular 2.0.x releases, it shows how active and dedicated we
>>>> are.  No one will think we're resting easy just because 2.0 is out the door.
>>>>
>>>> --Jeff
>>>> _______________________________________________
>>>> Amarok-devel mailing list
>>>> Amarok-devel at kde.org
>>>> https://mail.kde.org/mailman/listinfo/amarok-devel
>>>>
>>>
>> _______________________________________________
>> Amarok-devel mailing list
>> Amarok-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/amarok-devel
>>
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>