Contour/Active global context menus

[Sebastian Kügler]

Hey,

On Wednesday, May 25, 2011 00:12:55 Marco Martin wrote:
> from the mock up in contour of context menus specific to a certain type of
> resource, we are using this design to have context menus anywhere whe show
> items linked to any nepomuk resource.

I saw that in your video, there's a tip under / above the context menu. Is 
that something you've added to the theme? I don't get this tip. But it looks 
pretty neat :)

> the goal is:
> * having everywhere, in any Plasma widget the same delegate for resources,
> so the exact same representation, dependent to the type of the resource.
> 
> * is possible to do a set of actions on each resource, some actions common
> to every resource, some dependent from the resource type
> 
> * a common context menu, that is the same when invoked from any applet, and
> shows the exact same set of actions everywhere
> 
> what can the actions be?
> some common could be
> * rate
> * add tag
> * (dis)associate to the current activity

Some things that come to my mind...

* remove (in case of bookmarks, simply the resource is removed from the 
  nepomuk store)
* Trash / Delete (in case of files)

> others can depend from share-like-connect

and those :)

> so, we did  two similar plugin systems, that both for the resource delegates
> and for the menu items themselves can load qml files which path can depend
> from the resource type (and from the action name, for menu actions, since
> the rate widget will have to be different from a simple text entry)
> 
> now, from where the actions come?
> right now there is an hardcoded qml ListModel for each resource type that
> lists them, but this isn't an optimal solution for sure.

We could use an ActionModel per resource delegate, and put them in the same 
dirs, per resource type, so with a FileDataObject/ListItem.qml we'd load 
FileDataObject/ContextActionModel.qml, and possibly special FooMenuItem.qml in 
there.

> the actions come from dataengine services, so what is needed for an action
> is: 
> * the localized display name of the action
> * which dataengine is from
> * which source is the service
> * which service operation is
> 
> if the service operation parameters are different than the simple resource
> url, i didn't find other solutions than having to provide a different item
> specific for the action that calls the service with the proper parameters
> (see plasma-mobile/bindings/mobilecomponents/menuitems/rateItem.qml)
> 
> the dataengines that would support those kind of actions would be basically
> 2: metadata (and derivatives) and what will be share-like-connect
> 
> so, instead of an hardcoded model, i am thinking to show the list of actions
> as a data source of metadata (and slc when it will exist),
> so we would have:
> ActionsForResource:(nepomuk url), with keys like
>    * "rate"  hash(name->i18n("rate"), operation->"rate")
>    * "addToCurrentActivity" hash(name->i18n("add to the current activity"),
> operation->"addToCurrentActivity")
> 
> the context menu would show those actions coming from the two dataengines,
> as possible operations get added to the dataengines they will all get
> available everywhere

Hm, could also lead to clutter in the UI...

> a part that i would really need feedback, is how to generate that action
> list, a way can be from the dataengines as described, but i feel there can
> be still room for improvement.
> suggestions? comments?

The JavaScript Service API lists those methods, that would at least list the 
available operations, but not the parameters.

function operationNames()
function operationDescription(QString) 

Another thing, not all operations might be interesting in the UI, I think it 
would actually be fine to "hardcode" the actions in the ActionsModel (if 
necessary, we can share code among them, but it seems mostly relatively simple 
functions). The harder parts are done in the ServiceJob in C++, the ui-logic 
is done in the either the resourcedelegate directories, that's where you can 
"disambiguate" the actions (remove means something different for a bookmark 
than for a file, for example). Seems like a logical split to me.

So I think this kind of UI-level logic should be in the QML files, using a 
small javascript function. Like it's now :)

Great work, btw. :)

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9