[Kde-pim] Re: Shortcomings of StandardActionManager?

[Ingo Klöcker]

On Tuesday 01 March 2011, 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....
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Just checking if I'm missing something here =)
> Maybe there is a reason that it was implemented that way.

Standard actions are supposed to be actions which are always there (but 
not always enabled) and which are context independent (except for their 
enabled state).

I don't see how you want to add context-dependent behavior to an action 
which cannot know anything about the application specific context. How 
would this standard action know that it should show one or the other 
text? How would it know that it should be available or not? This will 
have to be controlled by the user app anyway. So I don't see a problem 
with letting the user app also do the other work.

Of course, it would be cool if most/all of the functionality would be 
provided by the backend. But I don't think using standard actions is the 
right solution for this. (I could be wrong, but your findings appear to 
prove that standard actions don't work for your use case.)


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20110301/02520bf1/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/