User actions/toolbars plugin

Andras Mantia amantia at
Fri May 20 15:24:03 UTC 2005

> Hi Andras,
>> So should I drop the idea of making this a plugin and integrate into the
>> main shell? Anyway this would be a core plugin/functionality. The
>> question is which mainwindow implementation should I pick up. ;-)
> please do not do this. Let us see how we can find a solution. I am sure
> there
> is a way to do this without touching KDevelop at all.

I'm not so sure, but if we find, I'll be happy.

> Looking around in the docs let's me think in this direction:
> 1. We want to have one toolbar with a tab widget inside
> possible solution: create an empty toolbar in the xml file of the plugin
> and
> add the tab widget manually in the plugin.

Sure, we can do this. It is possible to add any widget to a toolbar, but
in this case you cannot configure the user toolbars with the standard
Configure Toolbars dialog, as for the user toolbar there will appear only
one item: the widget on the toolbar holding the other toolbars.

> 2. we want to create a toolbar but this should not appear like a normal
> toolbar in the mainwindow.
> possible solution: since the user toolbar is a KXMLGuiClient it has a
> method
> setClientBuilder(). In theory we can add our own builder here that gets
> used
> when kmainwindow's factory builds the toolbar. In this custom builder you
> overwrite the addClient() method like in Quanta's mainwindow.

I'm not sure this will solve the above problem.

> If you create a tabwidget object that inherits from KXMLGUIBuilder you can
> easily add the created toolbar directly to the tab.
> If this is well done we might add a configuration switch so that the user
> can
> decide if s/he wants to use the tabwidget or let the toolbars appear like
> normal toolbars in the main window. We only have to use our own builder or
> the builder from the mainwindow.
> Does this sound feasible for you?

If it solves the configuration problem, yes. You know, it would be pitty
to loose such functionality as it saves a lot of code, as we don't need to
deal differently with the user toolbars and the actions on it from the
rest of the toolbars.

> Jens
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at

More information about the KDevelop-devel mailing list