KToolbar Confusion

Simon St James kdedevel at etotheipiplusone.com
Thu May 14 19:39:39 BST 2009


Hi all,

Follow up from http://lists.kde.org/?l=kde-core-devel&m=123325087220541&w=2; 
working towards a fix for:

http://bugs.kde.org/show_bug.cgi?id=168480 and 
https://bugs.kde.org/show_bug.cgi?id=169067

Not much feedback on the original post (but thanks to dfaure for explaining 
that some of my assumptions were wrong :)), so I figured I'd try to work out 
the requirements myself, write a patch implementing them, and let people pick 
it apart in order to tease out the full spec ;) The attached does just that: 
it "works", but I'm sure there's lots and lots of incorrect assumptions 
there - I have no objection to throwing it all out and starting from scratch 
once I have a spec.  It could probably be made a simpler if we assume that 
e.g. loadState and saveState are only called at specific, predictable times, 
but they are public API and I can't bring myself to do this ;)

Note that global changes to toolbutton style are not yet automatically 
responded to by apps: this will require extra changes to the Style KCM to 
make it actually write the changes to the kdeglobals file(!)  Doing 
this "manually" and firing the relevant signal makes the apps update their 
toolbutton style settings, if appropriate, correctly though. Icon size should 
Just Work.  I'll fix the KCM Style once I've gotten the KToolbar stuff 
hammered into shape.  There's a small System Settings patch which may or may 
not be required in order to detect changes to the global default icon size - 
again, something I'll sort out later :)

My assumptions - please review and correct :)

1) An icon size/ toolbutton style is the Default (capital "D"!) if it has not 
been specified explicitly in the apprc nor via an API call to 
QToolbar::setIconSize/setToolButtonStyle nor via the user choosing an 
explicit size in the toolbar context menu.  An icon size/ toolbutton style 
can be reverted to Default by choosing "Default" from the toolbar context 
menu.  In particular: Just because e.g. the current size of the icon is 22 
and the global default size for icons is also 22, it does not follow that the 
icon size is the Default - it may have been manually set to 22 by the user!

2) The "Text Position" (toolbutton style) context menu should really have 
a "Default" option to match that of the "Icon Size" context menu.

3) The Default for the icon size/ toolbutton style can be a) hard-coded; b) 
loaded from relevant group(s) in the kdeglobals file; or c) specified in the 
xmlgui appnameui.rc.  This list is given in order of precedence: kdeglobals 
overrides the hard-coded defaults and xmlgui overrides this.

4) If the icon size/ tool button style is Default, it should track the actual 
defaults as they change: In particular, if the defaults originate in 
kdeglobals, then they should track changes made to the kdeglobals default 
values via System Settings kcm's.

5) The default value for the icon size/ toolbutton style can be specified via 
xmlgui using the "iconSize" and "iconText" attributes.  Thus, if e.g. 
iconSize=xx is specified for a toolbar in the appnameui.rc, then as a 
consequence of the precedence described in 3), the icon size for this toolbar 
will *not* track the kdeglobals default icon size.  This does not affect the 
non-Default status of icon size/ toolbutton style i.e. if the icon size was 
Default prior to a call to loadState(...) and loadState(...) found 
iconSize="32" in appnameui.rc, then the default icon size is set to 32, and 
the actual icon size is still Default - it does not count as explicitly 
setting the icon size to 32.

6) If the icon size/ toolbutton style is the Default, it should *not* be saved 
in the appnamerc - otherwise it should.

7) If the icon size/ toolbutton style is the Default, it should *not* be saved 
in a call to saveState - otherwise it should.  I guess if they have 
non-Default values they should be saved as "iconSize" and "iconText", but the 
only related thing that is actually currently saved is "toolButtonStyle"(?).

8) If the value of the default icon size/ toolbutton style did not originate 
in xmlgui, then it should not be saved in saveState - otherwise it should.  
I.e. - if the appnameui.rc did not provide a "iconSize" attribute for this 
toolbar, then "iconSizeDefault" should not be saved in saveState - this 
avoids the case where a future call to loadState retrieves iconSizeDefault 
(which may have originated from kdeglobals), identifies this as coming from 
xmlgui (overriding kdeglobals, as per 3)) and thus prevents a Default icon 
size from tracking the changes to the default icon size in kdeglobals when it 
really should.

9) If an icon size/ toolbutton has been manually set via an API call to 
QToolbar::setIconSize/setToolButtonStyle or via the user choosing an explicit 
size in the toolbar context menu, then re-loading from a config group via 
applySettings(...) will not override these manually set icon size/ toolbutton 
unless "force" is true - this is  debatable and I would appreciate input on 
it :) It makes some sense to me as if the user specifies explicit values at 
runtime, these should not be overridden i.e. manual changes should have 
highest "precedence".  This is still a TODO.

Many thanks for any advice; I'd really like to get this nailed before 4.3, but 
can't without the help of people "in the know" :/

Best Wishes,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ktoolbar-systemsettings.patch
Type: text/x-diff
Size: 525 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090514/9b05c917/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ktoolbar.patch
Type: text/x-diff
Size: 19663 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090514/9b05c917/attachment-0001.patch>


More information about the kde-core-devel mailing list