Standardizing Context Menu Actions

[Maximilian Kossick]

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
>