[Kde-pim] Re: Shortcomings of StandardActionManager?

[Christian Mollekopf]

On Thursday, April 21, 2011 09:41:34 AM Volker Krause wrote:
> 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.

The problem was that i wanted to create a list of actions:
If not in trash: single "move to trash" action
If in trash: "restore from trash" and "delete" actions

Since I couldn't find a decent way to do that, I'm just using the default 
delete action, which is always visible (also for items which are not in 
trash).

Anyway I'm not that sure if this would have been a good idea in the first 
place, so I'm fine with the current state.

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

I managed to get that working with the new ActionAlternative action type.
You will see once you'll review ;-)
> 
> > 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.

Indeed, that would be a solution.

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

I see... Fortunately not a problem for me as I only use items =)
> 
> > 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).

Ok, I think I'm fine for the moment with what we have =)
As you said, most apps probably use their own actions if they have advanced 
needs, so the standards for the trashhandling should be ok (At least the work 
for so far).

Thanks for the insight,

Cheers

> 
> regards
> Volker
_______________________________________________
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/