Icon choosing in kedittoolbar

[David Faure]

On Thursday 29 April 2004 22:36, Andras Mantia wrote:
> On Thursday 29 April 2004 23:20, David Faure wrote:
> > On Thursday 29 April 2004 22:03, Andras Mantia wrote:
> > > Isn't factory()->addClient() an xmlgui way to add them?
> >
> > Yes it is. But that's not what I'm talking about. See the
> > action->plug() call in the code!
> 
> Yes, for plugging it into a menu and ...

No, you also manually plug actions into toolbars. I digged a bit into the code
and found where: 
quanta_be: [virtual QWidget* QuantaApp::createContainer(QWidget*, int, const QDomElement&, int&)] manually plugging action tag_color

> > The addClient call does nothing,
> > since the action collection of the client is empty.
> Yes it does. It calls the createContainer, where our special toolbar is
> created and the action is plugged into it. 
Reimplementing createContainer is fine (and the correct way to create special containers),
but plugging actions there, is only asking for trouble. This isn't how XMLGUI works. 
Note how KXMLGUIBuilder::createContainer *only* creates a container (widget),
but does NOT plug any action into it! That's not its job. That's the job of
KXMLGUIFactory. But for that it has to find the actions, which it can't do if
they have the wrong parent collection.

> I've tried to pass the xmlgui's actionCollection to the KAction
> constructor, but the result was the same.
Well you apparently need to fix much more than that, in particular letting
the normal xmlgui plugging mechanism do its work (you're creating a real toolbar,
so AFAICS it should work, if xmlguifactory can find the action).

Hmm, but still kedittoolbar would find the action if it's in the collection.
Please triple-check that toolbarGUI->actionCollection().count() > 0

> The problem is that with automatic xmlgui behavior (a simple addClient)
> you cannot put a toolbar into another widget (a QTabWidget in this
> case).
Yep, I understand why you reimplement createContainer, and that's fine.
It's the action handling that's very dubious.

> > The more hacks you pile up, the more chances you have that something
> > doesn't work :)
> This is true.
Then I hope you'll agree with me that your suggested kedittolbar hack is
definitely a no-no. It might work for you because you iterate over all
your actions yourself in createContainer, but no other application does that.

(next mail)
> You should
> be able put every action of the main application to such a toolbar and
> every action loaded together with a toolbar may go to (let's say) the
> main toolbar. 
Then you need to either
1) edit the mainwindow's own XML, instead of adding separate clients to it
or
2) insert all the mainwindow's actions into the client's actionCollection, to
make them available to it. With the new kedittoolbar, it won't even give
duplicates in the left listview of kedittoolbar. 

> But as currently KEditToolbar looks for
> the actions present only in the xmlguiclient, it won't show anything.
You're picking the wrong fight. It's XMLGUI that look for actions present
only in the xmlguiclient, in the first place !
KEditToolbar is only applying the same principle.

> Adding them to the xmlguiclient's actionCollection would not solve the
> problem, as in the left listview I would not see all the actions from
> all the loaded toolbars and the standard mainwindow actions.
Well, you would, if you add all the actions, wouldn't you?

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).