[Kde-pim] Re: Shortcomings of StandardActionManager?

[Volker Krause]

On Tuesday 01 March 2011 11:25:30 Christian Mollekopf wrote:
> Hi,
> 
> Im trying to implement StandardActions for the akonadi trash handling.
> Ideally I would add the following actions to the menu:
> 
> If not in trash:
> -Action: Move To Trash
> 
> If in trash:
> -Action: Restore from Trash
> -Action: Delete
> 
> I doesn't seem to be possible however to implement this in the
> StandartActions framework....

The StandardActionManager (SAM) knows the collection selection model, using 
that you should be able to determine if you are in the trash folder or 
somewhere else, and adjust actions dynamically.

> First, I can't change the Action text. If I want the same action for move to
> trash and restore from trash, I would have to dynamically change the text.
> If I can't do this,  the user app has to manually check if the item is in
> trash or not and insert the correct action, which renders the
> StandartAction essentially useless.

Hm, are you trying to implement this in SAM or extend SAM externally? In SAM 
itself it shouldn't be a problem, you have full access to the KAction object 
there. Extending it externally is not really supported though, since we 
haven't figured out a good way of supporting this.

> Second, I can't dynamically add/remove actions, but only enable disable
> them. In Trash you should have two options: Definitely delete the item, or
> restore it. If the item is not in trash, this is not necessarily the case.
> It should be up to the user app to offer a delete option if desired.

While adding/removing might not be possible, hiding/showing should work, with 
pretty much the same effect.

> Third, It is somewhat complicated to offer options which work for items and
> collections. I don't really get why the delete item and the delete
> collection actions exist and there isn't a delete entity action. I don't
> see any reason not to implement a single action, except that it is not
> possible currently to dynamically change the text as mentioned in point
> one.

There is a deeper problem with this, there are cases where you cannot decide 
whether to delete the currently selected folder or the selected item. Think of 
pressing the "Delete" shortcut in the main view of KMail, it's focus-less (ie. 
all actions behave the same, no matter which list view technically has the 
focus). Duplicating the actions is of course an ugly workaround for this, but 
we haven't found a better solution yet.

> So, should I just extend the StandardActionManager internally?
> 
> I don't know if it is even possible that a single action definition in the
> kxmlmenu expands to several actions, but at least that the same action has
> several different texts should be doable, although this will further
> complicate the whole class as I don't think I can integrate it in the
> existing functions.

There is support for action lists in XML GUI, I've used that once a long time 
ago for a bookmark menu IIRC, so this should be possible.

> Just checking if I'm missing something here =)
> Maybe there is a reason that it was implemented that way.

The main reason is the lack of a better design for SAM at the time it was 
written. There is so much shared code in action representation, action state 
management and the actual operations it seemed like a good idea of putting 
that into the library back then. But when used in practice we noticed that 
applications want to customize all kinds of aspects of this, and extend it by 
its own actions. There are also type-specific versions of SAM (mail, contacts 
and calendar at least), they run into similar problems with lack of 
customization/extension hooks.

At some point we came up with a more flexible design, which so far hasn't been 
implemented, but it's documented on techbase somewhere (possibly as part of 
some meeting notes, can't look that up right now unfortunately).

regards
Volker



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20110421/89b93d10/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/