Main Toolbar/Toolbar in QToolBar
David Faure
faure at kde.org
Wed Aug 14 11:58:44 UTC 2013
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
More information about the Kde-frameworks-devel
mailing list