Fwd: changes in kcontrol

[Aaron J. Seigo]

-----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 panel, 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?

- -- 
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)

iD8DBQE9Mw3a1rcusafx20MRAk/sAJ9LWSxrA/a3bK3tUBJiHvo6Hx1knQCgiYlv
8QHfNqDiR6NRoen+cKbKHdo=
=nk6m
-----END PGP SIGNATURE-----