KDE Control Center

Aaron J. Seigo aseigo at olympusproject.org
Mon Aug 5 04:48:13 BST 2002

Hash: SHA1

On Sunday 04 August 2002 05:11, Stephan Binner wrote:
> On Sunday 04 August 2002 22:49, Aaron J. Seigo wrote:
> > one of the strengths of the kde control center is in inclusivity; if they
> > want to configure something they go the control center.
> Then Konsole module would have to stay and KMail's be integrated too. ;-)

konsole is a common component embedded in several places (konsole, konqueror, 
kdevelop). kmail is not.

that said, i do think that all the component/application configs should be 
moved elsewhere.

> > it hasn't ended up with the removal of the look 'n feel category (though
> > i remember that being one of the goals) and has given us categories such
> > as
> Was this a goal? I remember "Personalization" was planned to be removed be-
> cause "it's all about personalization"

hrm. i thought i remember charles speaking about being rid of look 'n feel a 
few times on IRC. perhaps i've misremembered it and he was actually speaking 
about Personalization. wouldn't be the first time =)

> but I find "Look & Feel" a good term
> for what it now contains: GUI related settings which apply to every KDE
> app.

that would make sense, except we have things in there like screensaver. and 
then we have some look and feel things elsewhere, such as icons on the 
desktop settings.

> > "advanced" (what belongs in advanced? more importantly: how can a user
> Settings rarely used by only a couple of users is my best description. :-)

and how are users supposed to figure that out? people know what they want to 
configure and they try and locate the appropriate panel based on that 
information. if someone wants to configure their address book or their 
desktop paths, how are they to know that they are "advanced" settings? 

why, for example, is the "Paths" panel in advanced? does it not pertain 
primarily to the desktop? and what "paths" are these? advanced paths? at 
least when it was under "Desktop" one had a fighting chance at guessing what 
they were. "Desktop / Common Locations" might be more expressive?

what makes accessability advanced?

moreover, most of the things under advanced are actually 
components/applications. perhaps they should be a group unto themselves. 
Common Components or Application Parts as a header with those items would be 
far more expressive than "Advanced". at least then one might guess where 
"Component Chooser", "Spellchecker", "Konsole", etc would be.

> > previous to this round of changes i had gone through and counted
> > duplicate or redundant panels and figured we could eliminate probably a
> > quarter of the panels through combination and reorganization while
> > reducing the complexity and increasing the clarity of each! the problem
> > is only more
> If you already figured it where is your list :-)? Anyway thanks for
> opinion.

my list became rather irrelevant as there is no relationship between what was 
there and what is there. once the current "hack and slash things into 
individual panels and reorder them into various categories" business is 
finished i'll probably take up my efforts on kcontrol anew.

of course, i really wasn't planning on suggesting a huge reorg of the tree 
structure, since after looking at things it became rapidly apparent that the 
real problem was the sheer number of panels and the lack of organization of 
the settings they contained. 

a great example of this was the 4 or 5 power control panels, which are now 2 
panels the last time i checked. almost as if to counter this win they are now 
found in a subcategory of a subcategory, which is a total abomination: users 
have a hard enough time with a single level of hierarchy. forget about 2 or 
more levels.

the great hilarity is that the #1 problem with the control panels as users 
expressed it was the sheer number of them. our attempt to make kcontrol more 
usable has therefore been to inflate this number? 

furthermore, the new names picked for the panels appear to be their old names 
from when they were integrated as a tab on a larger panel. Web Browser -> 
Plugins should probably be called Netscape Plugins since that is what it 
controls, not Konqueror plugins which is one would probably guess given the 
current name. this wasn't such a huge issue previously since the user wasn't 
exposed to the name of that tab as a stand alone panel. now that it is one of 
the destinations they can pick to visit from the tree, the ambiguity in that 
name is detrimental to the predictability of kcontrol (e.g. can the user 
predict what will come up when they pick something?), which will only erode 
user comfort with the panels and further the impression that they are poorly 

have you (or whomever is doing this) actually tested any of these changes on 
the users you are trying to help? or are these changes largely ad hoc?

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

"Everything should be made as simple as possible, but not simpler"
    - Albert Einstein
Version: GnuPG v1.0.7 (GNU/Linux)


More information about the kde-core-devel mailing list