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

On January 07, 2004 11:01, Frans Englich wrote:
> Right, the structuring(naming, hierarchy) depends on navigation and is all
> changed in one bundle. But there is still things which are for sure, 
> independent of navigation/Layout:

i don't really agree with either statement made here. they _may_ be true, but 
they are also equally likely to not be true.

> * There will for most likely be a "Hardware" toplevel(somehow) category for
> example, and this allows some "filing" done.

so perhaps we should _start_ with the "toplevel (somehow) category)" bits 
first (aka the interface). because if this turns out that when creating the 
navigation interface we end up with an approach other than what we expect 
right now then we will have wasted time, efforts, etc.

cart before the horse.

> * The content of the kcm's will not change and their names can be changed
> to better reflect content. Other cosmetic name changes can be done.

"can" doesn't mean "should". when placed in the context of a new interface, 
the cosmetic decisions may well change. a new interface may also allow us to 
keep some of the details users are already familiar with that we may 
otherwise wish to change to make up for the current interface....

> * Agree on whether application specific settings should reside in KControl

i believe this has already been agreed upon a while ago, and the conclusion is 
that only applications which are not seen as distinct from the desktop should 
be there.

> and how much administration-ish stuff should be in KControl(or somewhere
> else).

this is a question that, given a proper kcontrol interface, would likely sort 
itself out ... there are many similar self-solving problems when a proper 
interface is provided, which is why i'm not keen on entering another reorg 
discussion prior to revisiting kcontrol's basic interface.

> * Merge similar kcms.

... when it improves things ;-) not every possible merge will be an 
improvement. other kcms could be pulled apart and put together in new ways 
such that 2 given kcms may result in 2 new kcms that have a better grouping 
of settings. one of the annoyances here is that this can often lead to 
touching multiple kconfig files in each of the new kcms which in turn means 
having to modify (and test) more panels when changing those parts of the 
desktop that dictate those settings.

- -- 
Aaron J. Seigo
while (!horse()); cart();
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE//FSa1rcusafx20MRAv8tAJ0R/wmuMt56SKhcxNhzuzLLDX8UlgCfcdcl
MkOq2T4D7BP8MyHOw3YHFlc=
=9/tc
-----END PGP SIGNATURE-----
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-usability