Main Toolbar/Toolbar in QToolBar

[Kevin Ottens]

On Wednesday 14 August 2013 17:25:15 Kevin Ottens wrote:
> On Wednesday 14 August 2013 16:45:50 Aurélien Gâteau wrote:
> > 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.
> 
> Note that anything which involves XmlGui doesn't cut it as... well... XmlGui
> contains KToolBar anyway. :-)

Actually makes me wonder what we're trying to solve... Let me try to summarize 
the situation for my own understanding (stop me where I'm wrong):
 * Current code uses KToolBar;
 * Code using KToolBar follow our settings properly (has access to all 
necessary dependencies);
 * Code using QToolBar doesn't follow our settings;
 * We can't force our settings on random QToolBar, but code using those is 
outside the port to KF5 code, that would be new code from our point of view;
 * In QToolBar using code, developers can choose to use 
Qt::ToolButtonFollowStyle so that the toolbar follow our settings properly 
(except for the main/regular toolbar distinction).

Is it me or we just need a method in KWidgetsAddons to declare which toolbar 
of a window is the main one? That choice is obviously in the hands of the 
application developer, And that would be used only in new client code. All 
other toolbars to be considered regular ones.

Alternatively to a dynamic property that could be a static property on 
QToolBar... but that requires patching Qt and I suspect it wouldn't go in.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

Sponsored by BlueSystems and KDAB to work on KDE Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130814/06500cbb/attachment.sig>