xmlgui doesn't honor toolbar position

[Albert Astals Cid]

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?

> But I don't know what's the
> current status on that patch (i.e. the opinion of QtSw about it). 

I'll manually ping him when he wakes up but i don't have a good feeling about 
it giving his been a bit away from KDE coding lately.

> 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, but really if we had a HIG i guess 
it would mandate the toolbars being on the top, so probably the answer to your 
question is no, it's not worth the trouble.

Albert