The future of KAction

[Simon Hausmann]

On Wednesday 16 November 2005 15:35, Alexander Dymo wrote:
> On Wednesday 16 November 2005 12:01, Andras Mantia wrote:
> > On Wednesday 16 November 2005 11:38, Christoph Cullmann wrote:
> > > btw., other important thing: it needs to be possible to remove the
> > > gui elements the plugin/part has added without deleting the
> > > plugin/part in a sane way, like atm possible with unplugging the
> > > xmlguiclient.
> >
> > Exactly. Actually I need a way to save and restore some gui elements
> > (like actions only, or actions on a toolbar) without needing a full
> > KPart.
>
> I think GuiEditor is exactly you're asking about. I can only guess what's
> GuiEditor in Simon's interpretation, but I does not look like a KPart.
> Therefore you can do whatever you want like:
> editor.hide(); // ~ unplug
> editor.removeAction(myAction);
>
> Simon, am I right with that? Do my proposals above have any sense?

Yes. I think GuiEditor itself should just be a frontend tool class, just like 
QPainter.

As 'backend' I would like not to use anything dedicated though, but instead 
try to map everything to the existing API. So for example a action group 
placeholder would just be an invisible separator QAction. And in order to 
determine to which component an action belongs to we could just look at the 
parent(), and by that require actions to have proper parents. That also makes 
all actions automatically disappear from the GUI if the plugin is deleted.

> > Now I just save the xml file, load and create an xmlguiclient
> > and add to the factory. This functionality is needed in the future as
> > well.
>
> Hmm, that means that using the new approach you would need
> to save the action configuration manually. Maybe xml was not
> that bad ;) But anyway, it's easy to save the configuration manually.

Either that or we add support for reading xml/writing xml files. Perhaps it 
would make sense to use the same format as Qt designer/uic...

Simon