xmlgui doesn't honor toolbar position

[David Faure]

On Monday 29 June 2009, Albert Astals Cid wrote:
> A Dilluns, 29 de juny de 2009, David Faure va escriure:
> > On Sunday 10 June 2007, Christoph Pfister wrote:
> > > Hi,
> > >
> > > Toolbars in the .ui file may have the "position" attribute specifying the
> > > area where they are placed by default. However it's currently ignored
> > > (attached is a small testcase showing the problem) ...
> > >
> > > Can anybody shed light on this? Thanks in advance!
> >
> > Since I'm looking at ktoolbar settings currently I finally had a look at
> > this, but it seems to be fixed by now. Works for me.
> 
> There is a problem though. Changing the position only works if you don't have 
> a .kde/share/config/appnameuirc file, if you have it modifying the position of 
> the toolbar in your rc file won't do anything.

Right, that's due to the all-in-one QMainWindow::saveState (saved into the State
key in the config file). It cannot have the logic like "only save if different
from the app default" (since it's in Qt and doesn't know the app defaults).
I don't have a solution for this. We have to use QMainWindow::saveState
since QToolBar does not have a public API in Qt4 for positioning toolbars
in a specific order and offset... Well IIRC ereslibre pushed forward the idea
that offsets are not useful though (and made a Qt patch that prevents
moving toolbars to the right with a fixed offset, only allowing reordering;
makes sense to me). But I don't know what's the current status on that patch
(i.e. the opinion of QtSw about it). So if we exclude that, all that's left is
to add a QMainWindow::insertToolBar(int index, QToolBar* bar) and we can
do it like in kde3 again (not using QMainWindow::saveState, and saving
visibility+order of toolbars ourselves again).
However that had its pitfalls too; when adding/removing components,
the toolbar indexes become wrong, so I actually liked the idea of the
"all in one" saving because it represents correctly the complete state of
the window [including the positing dockwidgets, which is another topic
with similar issue since there's no public API for doing it otherwise].

Is the use case for "changing the default position of toolbars in a kde app"
big enough to be worth all the above trouble?

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