Icon choosing in kedittoolbar

[Andras Mantia]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

> 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. removeClient() calls the 
removeContainer, where the toolbar is removed (the actions are not).

> > The reason why I
> > do it like you saw is because this was the only way I could get it
> > work (don't ask me the exact problems, as I coded almost 2 years
> > ago).
>
> Well I think the exact problem is the wrong actioncollection as
> parent.

I've tried to pass the xmlgui's actionCollection to the KAction 
constructor, but the result was the same.

> > What
> > we do there is loading a toolbar XML and an action XML file and
> > creating a toolbar for it, which is not a standard KDE toolbar, as
> > it's in a tabwidget. This exposed many problems, and the way it is
> > now was the solution until now.
>
> A dynamically-generated XML for a guiclient sounds fine (and fun),
> but the actioncollection for that guiclient has to hold those
> actions, and you have to let xmlgui handle the plugging.

The problem is that with automatic xmlgui behavior (a simple addClient) 
you cannot put a toolbar into another widget (a QTabWidget in this 
case). 

> >  Hm, thinking more, I think one of the problems was this check:
> > " if (! actionCollection()->action(actionName))". If I put the
> > action in the newly created xmlguiclient's actioncollection, then
> > it's not trivial to look up if there is also an action with that
> > name or not. This action searching and juggling happens on other
> > places as well, and an action might move from one actionCollection
> > to another (or be present in two in that case), which makes things
> > even worser in the toolbar edit dialog (like duplicate actions). I
> > remember a version when I had to delete & move actions prior to
> > calling the edit toolbar dialog in order to get something useful.
> > The current way is the most cleanest so far I could create.
>
> The more hacks you pile up, the more chances you have that something
> doesn't work :)

This is true. I know that what we are doing is far from being a standard 
usage of XMLGUI, but it is a powerful and interesting usage: creation 
of dynamic toolbars(with actions) and save/load them from files.

>
> > > No wonder kedittoolbar is confused....
> >
> > It wasn't confused prior to yesterday. ;-)
>
> It certainly was. It showed all actions, sure, but did you try
> actually moving actions from the left to the right? 
Of course I tried (several times). I never saw any problem with it, I 
was even surprised to see your commit and how many times this bug was 
reported.

> In many cases 
> nothing would happen. With the new mechanism, it is guaranteed that
> any move done in the dialog will work in the real application.
>
> > Can you tell me from where do you got this code? I cannot find any
> > actionCollection()->insert now.
>
> The code was a bit old, it was from the old quanta module (oops).
> I'll update kdewebdev now :)
I don't have that even in the old module, so yours must be very old... 

> Anyway shouldn't matter, since we're both seeing the same.

Yes, of course. And this is quite important for us. This also means that 
every Quanta < CVS HEAD (and now even that one) will have the bug with 
KDE 3.3 (behavioral change of kdelibs). Well, we can live with it if we 
find a solution, so at least I can say that Quanta 3.2.3 and above 
works well with KDE 3.3.

Andras

- -- 
Quanta Plus developer - http://quanta.sourceforge.net
K Desktop Environment - http://www.kde.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAkWdXTQdfac6L/08RAnJsAJ93+rvAQdywvNRLvFOaOh3nJa1ODgCfThAk
If09Ql+vduk5g3aIACgwXRU=
=1RbE
-----END PGP SIGNATURE-----