xmlgui doesn't honor toolbar position

[David Faure]

On Sunday 05 July 2009, Albert Astals Cid wrote:
> A Dissabte 04 Juliol 2009 18:41:27, David Faure va escriure:
> > 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). 
> 
> Makes sense to me too, but how does that fix the problem of giving more power 
> to the xmlgui file than to the saveState info?

... because then we would stop using saveState and we would position toolbars
ourselves, as the paragraph below says.

> > 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?
> 
> I can think about standarization/personalization, for example, Maemo seems to 
> like having all the toolbars at the bottom

Sure, but if that's done before users start using the software, then it works fine ;)
It's only a problem during upgrades, if the developers changed their minds about
where the toolbar should go by default.

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