[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    changes in kcontrol
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-07-14 3:29:32
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi all...

kcontrol is going through massive changes. i like the general concept of 
moving to a more task/topic oriented structure. however...........

i've been trying to keep my consternation over the changes to myself ... i'm 
wondering more and more if this shouldn't've been done in a CVS branch rather 
than in HEAD since it is so invasive and experimental ... if this new reorg 
breaks down at some point (developer time, the model just doesn't work, 
whatever) it's going to be a bitch to roll it back ..

so since we're pretty much committed (excuse the pun) to this new approach, 
i'm left a little queasy for a number of reasons: 

 1) we are facing an absolute explosion in the # of panels available to the 
user as each tab becomes it's own pane, and we don't really know if it is 
going to be more usable in this fashion

 2) while there used to be some sort of basic sense to the organization of 
options on the tabs in respect to their names (e.g. the desktop kcm had 
appearance, behavior, etc...), now that they are broken out into seperate 
tabs they are looking absolutely horrid. take a look at desktop -> appearance 
and desktop -> behaviour ... do those options make ANY sense together now, or 
am i the only one that gets the feeling that when seperated it only increases 
the feeling of randomness?

3) we don't have a set of guidelines for the new panels resulting from the 
module break-ups. what should appear in a tab named "Appearance"? should 
desktop->appearance actually be named fonts? should desktop->behaviour be 
split further with the icon functionality split off? why is "Trash Path" in 
desktop->path but not desktop->trash?

4) bugs are being introduced and there is going to need to be a fierce amount 
of testing required to get kcontrol back into a known 100% working state. i 
know this from redoing kicker's kcm, but i also know this because i've found 
things that have become broken while going about with day-to-day 
reconfiguration (e.g. desktop->behaviour doesn't cause the desktop to refresh 
to the new settings)

5) icons. more panels == more icons needed. 

i suppose this "trial by fire" approach forces us in new directions (which may 
be the only thing that could help us overcome the general inertia w/regard to 
kcontrol), but i'm VERY concerned as to the amount of work that is going to 
have to be done between now and 3.1 (or rather, 3.1's feature/string freeze)

i'd feel much more at ease knowing that one or more of the people who work on 
KDE full time (paid, retired and lots of free time, whatever) were helping 
Charles on this ... as it is ... i'm a little jiterry...

am i out to lunch here? (please say yes)

/me is half wondering if this should be sent to core-devel as well... bleh.

- -- 
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9MPAc1rcusafx20MRAk9rAKCvtWQXTVSdBF9K5qQG6jc0fAX2twCfcD7+
9kShuTMAkT+1P6rNwhAvowU=
=cQD0
-----END PGP SIGNATURE-----

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]