The future of KAction
hausmann at kde.org
Sat Nov 19 10:55:51 GMT 2005
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
> 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
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...
More information about the kde-core-devel