Standardizing Context Menu Actions

[Maximilian Kossick]

On Sat, Nov 8, 2008 at 9:25 AM, Alejandro Wainzinger
<aikawarazuni at gmail.com> wrote:
> 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).

I don't understand what the problem is. When generating the list of
actions in the CollectionCapability, connect the action's signal to
QueryMaker::run, and connect newResultReady and queryDone (or whatever
it's called) to a small helper object, which waits for the queryDone
signal and then calls whatever slot is necessary to do the actual
work. That way the CollectionTreeView doesn't have to care about the
details of how the actions work. Doesn't that solve the problems
you're having?

> 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
>>
>