Main Toolbar/Toolbar in QToolBar

[Aurélien Gâteau]

Le mercredi 14 août 2013 16:06:07 Àlex Fiestas a écrit :
> On Wednesday 14 August 2013 13:58:44 you wrote:
> > > , of course there are exceptions but we
> > > can't move all these logic to Qt.
> > 
> > These aren't exceptions.
> > 
> > The definition of "Main Toolbar" was that it's the first mainwindow
> > toolbar.
> > 
> > You can't call other-than-first exceptions, they are very valid toolbars,
> > just not "main" :) Your code with a cast is wrong. Only one mainwindow
> > toolbar is the main toolbar.
> > 
> > The reason is that one might want large icons and text-under-icons to make
> > the main toolbar very intuitive, but still if the app has 5 more toolbars,
> > there's no room for such settings on the other toolbars, so they would be
> > "small icons only". A bit of an "easy mode" vs "advanced mode" split, in a
> > way.
> > 
> > > Applications needing this, will continue using XML-GUI or implement the
> > > logic by hand, I don't think there is something we can add to  Qt to
> > > make
> > > this easier.
> > 
> > The logic can't be in QToolBar itself, indeed. Which leaves the following
> > options:
> > * style hints as you suggested
> > * magic in kstyle (but not just a cast...)
> > * XMLGUI itself could inject the settings into the toolbars, possibly.
> > It already does to a large extent, maybe just not the defaults or
> > something
> > (didn't read that code in many years).
> 
> Yeah... apparently my assumption was wrong.
> 
> So what we need is instead is a way of "flagging/marking" a QToolBar as a
> "Main Toolbar" so our Style can do its magic, no?

A dynamic property would work, the question is which code would be responsible 
for setting it. KMainWindow and/or KXmlGuiWindow could do it, but that would 
keep the Qt vs KDE application distinction, since a QMainWindow based-app 
would not get it. On the other hand it prevents breaking Qt applications like 
Scribus, so maybe it's better this way.

Aurélien