default toolbar icon size settings

Scott Wheeler wheeler at
Fri Sep 27 11:22:51 BST 2002

Quoting David Faure <david at>:                 
> On Thursday 26 September 2002 22:12, Scott Wheeler wrote:                 
> > *) KToolbar doesn't check the right setting for toolbar icon sizes.                  
> > (patch attached -- though very possibly wrong)                  
> Who/what saves "Size" ? Why was this changed ?                 
> Why should the global and the local file have a different attribute                 
> name, when all others are identical?       
Look at kdebase/kcontrol/icons/icons.cpp (lines 224 and 328) -- I don't see        
anything in there that is saving to a field called "IconSize".  To check that       
I wasn't missing something somewhere I looked through       
~/.kde-cvs/share/config/kdeglobals and there's not a single "IconSize" key.               
My *guess* from looking at the code is that one point the toolbar icon size           
was stored in [Toolbar style] -> "IconSize".  However it now appears that the          
equivalent setting is in [ToolbarIcons] -> "Size".  The kcontrol source seems         
to confirm this.       
Again, I can't answer the "why" -- but it appears that it in fact happened.       
> > *) Why do we have different settings for "Main" toolbar icon sizes and                 
> > other toolbar sizes?                  
> This was mainly Kurt Granroth's doing. His idea was that in all                 
> applications, there's a main toolbar, and "extra" toolbars.                 
> People might want big icons with text under them, in the main toolbar,                 
> without having all the other toolbars become big at the same time (and                 
> occupying the whole screen).       
Does this really belong in global settings though?  Do you think users would       
want to configure this system wide?  Does it seem intuitve that after setting       
the "Toolbar Icon Size" that some toolbars won't respect that setting?         
It confused me, and that's why I'm asking.  I think at the very least there       
needs to be a wording change from "Toolbar Icon Size" to "Extra Toolbar Icon       
Size".  "Toolbar Icon Size" sounds generic, when it in fact is not.  Actually       
it doesn't even apply to *most* toolbars (since many/most applications only       
have one toolbar).       
> > (globally -- in a specific application, where these are                      
> > restored from the <app>rc file it makes perfect sense)  This seems                 
> > really counterintuitive.   I doubt most users have any idea what the        
> > "main" toolbar is.                 
> It's mainly the app which needs to know which one it is, not really the                 
> user.  But the idea was that it's quite obvious to the user too. I think it       
> is, generally.                 
Again, I think what confused me was the wording that I mentioned above.  I       
think most users would assume that "Toolbar Icon Size" affects all toolbars.        
If they know that there is a setting for "Main Toolbar Size" and "Extra       
Toolbar Size" *then* I think it *might* be intuitive which is which.       
If this were only an internal scheme, fine, but at which point a user trying       
to configure his icon sizes has to deal with this, I think it's a problem.       
> > What's worse is that only the XML client checks for "main" toolbar                  
> > settings, whereas when KToolbar is restoring the global default it                 
> > always (trys) to use the "non-main" toolbar setting.                  
> Hmm, should be easy to fix, since the toolbar is named "mainToolBar" if                 
> it's the main one.                 
Yeah, that should be pretty straightforward.  But I don't know this code, so       
I've been quite reluctant to change things or make assumptions.       
I'd like to check through all of the places in the libs that are doing       
reading/saving of toolbar icon settings to make sure that everything is       
working properly together.  I have a feeling that there are still some quirks       
going on.       
How does this list look?       
*) KControl sets the global settings       
*) KToolbar reads the settings for non-XML GUI toolbars      
*) KXMLGUIBuilder reads the settings for XML GUI toolbars    
*) KMainWindow::setAutoSaveSettings() uses KToolbar::saveSettings() to save  
application specific settings   
I will of course ignore applications that have written their own code for   
saving and restoring these settings.  And again, since I don't know this code   
in general, can you let me know if there's other places that I should be doing   
sanity checking?     
> > I'll probably look through for other places that the icon setting name                 
> > is inconcistant.  It looks like some of the KControl changes haven't                 
> > completely propogated through the classes that read global settings.                  
> Why do people who reorganize kcontrol change the way things are saved                 
> into config files? I mean, if the functionality hasn't changed.                 
> If it has, then the question becomes indeed - why hasn't the reading                 
> code been updated accordingly ;-)                 
Well, it looks like the icon size stuff (again guessing from the current code  
structure) was reorganized to handle icon configurations in a loop.  It would  
have required a special case to handle the toolbar settings, so it looks like  
they just created a new group for the toolbar icons.  Of course, as I  
mentioned, it looks like the changes didn't propogate to the code reading the  
settings.  (Lovely...)  
> The code related to settings in KToolbar is quite complex and touchy                 
> (check the big comment I added in applySettings()), I'd really prefer if it   
> didn't have to change, just because some key was renamed in some config file   
> for no particular reason....                 
> This needs investigation, I guess ;)                 
/me nods. 

More information about the kde-core-devel mailing list