[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-usability
Subject: Re: kcontrol redux, ad infinitum
From: Aaron Seigo <aseigo () kde ! org>
Date: 2004-01-07 18:48:58
Message-ID: 200401071148.58603.aseigo () kde ! org
[Download RAW message or body]
-----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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic