Quoting David Faure : > 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 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. -Scott