[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: Main Toolbar/Toolbar in QToolBar
From:       Aurélien_Gâteau <agateau () kde ! org>
Date:       2013-08-14 14:45:50
Message-ID: 1841752.ftloTsLYfD () trinity
[Download RAW message or body]

Le mercredi 14 ao=FBt 2013 16:06:07 =C0lex Fiestas a =E9crit :
> 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 toolbar=
s,
> > 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 m=
ake
> > the main toolbar very intuitive, but still if the app has 5 more toolba=
rs,
> > 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, i=
n a
> > way.
> > =

> > > Applications needing this, will continue using XML-GUI or implement t=
he
> > > 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 followi=
ng
> > 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 responsi=
ble =

for setting it. KMainWindow and/or KXmlGuiWindow could do it, but that woul=
d =

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 li=
ke =

Scribus, so maybe it's better this way.

Aur=E9lien
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
[prev in list] [next in list] [prev in thread] [next in thread]