Main Toolbar/Toolbar in QToolBar

[David Faure]

On Tuesday 13 August 2013 15:33:59 Àlex Fiestas wrote:
> On Tuesday 13 August 2013 15:05:46 Christoph Feck wrote:
> > On Tuesday 13 August 2013 14:00:37 Àlex Fiestas wrote:
> > > Effectively a Main Toolbar is usually a toolbar that is a child of
> > > QMainWindow while a "ToolBar" is a toolbar who's parent is another
> > > QWidget.
> > 
> > A secondary toolbar is every toolbar not called the "Main Toolbar".
> > For example in Konqueror, the "Extra Toolbar" or "Bookmark Toolbar".
> > So they are also children of QMainWindow.
> 
> Yes, that's why I said "effectively"

Can't see the relation with the word "effectively" :-)

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

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5