[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-active
Subject:    Contour/Active global context menus
From:       notmart () gmail ! com (Marco Martin)
Date:       2011-05-25 16:38:59
Message-ID: 201105251838.59316.notmart () gmail ! com
[Download RAW message or body]

On Wednesday 25 May 2011, Sebastian K?gler wrote:
> 
> > 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.
> 

yup, this is also a possibility, i could see two problems with it:
* that those delegates are getting quite fatter and there is going to be a 
separate instance for each item)
* would not be possible for action to automatically appear once slc supports a 
new action (model would have to be manually pathched)

i could see also some advantages, however ;)
* would be somewhat easy to implement, we are already not far from it
* would be easy to provide a pretty stable, properly size and not ever 
changing list of actions

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

yep, it should be not teh everything, but just a few relevant things

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

yes, it wouldn't be just listing of service operations, that's why i tought 
about an actual dataengine source, that would cope a bit better with dynamic 
entries and scoring of entries (what could be used as scoring criteria? or 
does the idea of scoring actions make sense at all?)


Cheers,
Marco Martin

[prev in list] [next in list] [prev in thread] [next in thread]