[Kde-pim] Re: Shortcomings of StandardActionManager?

[Christian Mollekopf]

On Tuesday 01 March 2011 21:16:01 Ingo Klöcker wrote:
> 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).

Ok, that explains why it is also not easily possible to provide such actions.
> 
> 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.
> 
Here are some examples of actions which are different  depending on the 
context:

-Entity delete action: I really don't understand why there has to be a 
collection delete and an item delete action. I certainly wouldn't want to offer 
both in the menu, having always one disabled. Rather this should be a single 
action, which changes the text ("Delete Folder"/"Delete Item") depending on 
what entities are selected.

Same goes for copy/move/cut/....

I don't see any reason to have so many actions doing essentially the same and 
letting it up to the userapplication to decide which to show.

-Trash handling:
As lined out in the initial mail, depending if the item is already in trash or 
not, the action should allow to move to trash, or to restore/delete the 
entity. Again I don't see a need to handle items and collections differently.

For all this the only context which is needed is the item/collection which is 
activated. For delete/copy/move/etc the item/collection itself is enough, for 
the trash handling the entity has an attribute providing the necessary 
information.

> 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.)
> 
The current implementation is definitely not created for this usecase, but I 
believe it would make perfectly sense to create such a framework or change the 
existing one to support this.

I think I will just provide some actions as it is currently implemented (not 
context aware) for now, so I can actually get the trash handling in trunk. 
I'll probably look into implementing the context aware actions later on.
(I'd be interested though if other devs would also like to see context aware 
actions, and if not, why not =)

Thanks for the comments,

Chris
> 
> Regards,
> Ingo
_______________________________________________
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/