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

List:       kde-usability
Subject:    KControl brainstorming in all its aspects
From:       Frans Englich <frans.englich () telia ! com>
Date:       2004-01-07 4:07:02
Message-ID: 200401070507.02204.frans.englich () telia ! com
[Download RAW message or body]

On Sunday 04 January 2004 16:21, William Leese wrote:

Ok. Let's make something concrete out of William's suggestions. We make a 
(giant) list with appropriate changes(which we agree upon) for kcontrol and 
add it to CVS as kcontrol/TODO. Note, this list is exactly brain storming, no 
ideas is proposed for commiting. Also, let us don't hold back ideas because 
of implementation issues(resonably :), who knows what comes up.

A lot of the ideas is from William's paper, I hope no one's offended.. Also, 
considering the mix of authors and the wild ideas - I assume people will 
defend the matters they find important and don't hold people responsible - 
this is just one big heap of rambling ;-)

First off, a list of name changes, feel free to answer with an ACK or reject 
it(with explanation :)

O:ld name
N:ew name

O: Component Chooser
N: Default Applications

O: Vim Component Configuration
N: Vim 
//Shouldn't this one be moved out anyway?

O: KDE Wallet
N: Wallet
//this one relies heavily on the metaphor..

O: Peripherals
N: Hardware

O: Display Power Control
N: Monitor 
//assuming it stays in "Power Control"

O: KDE Components
N: ?
// A lot of it moved to other places anyway.

O: k3bsetup2 
N: CD Writing
// or burning? This have been discussed before, I think there were some 
translation issues..

O: Country/Region & Language
N: Country & Language

O: Sony Vaio Laptop Hardware
N: Sony Vaio Laptop

O: System Administration
N: I don't know.. it sounds so serious.. especially Administration..

* We must standardize on whether to use Display or Monitor.

* As William points out, in a lot of cases there's unnecessary use of 
"Manager" and "Configuration" which is already clear. Should we settle on 
something, allow or disallow it? In either case, it must apply consistenly.


------------- Moves/Refactoring/Merging --------------

* Merge "Appearance & Themes/Panel" and, ehh, "Desktop/Panel". I have a patch 
for this.
 
* Remove "Peripherals/Monitor Gamma" - it's available as a tab in Display(!).  
It's amazingly that this duplication have not been discovered before. A 
NoDisplay=true for 3.2?

* Move everything in "Power Control" to "Peripherals"("Hardware")

* Merge "Power Control/Display Power Control" with "Peripherals/Monitor"

* "Internet & Network/Preferences" must somehow be removed.. Come on.. the 
timeout values really doesn't need to be changeable and "Mark partially 
uploaded files" can be set as default. I don't know about passive FTP.

* "Sound & Multimedia/Mixer" will probably be removed. Christian Esken will 
see to it if I understood him correctly.

* Remove "System Administration/Linux Kernel"(into "KAdmin"). This is too much 
demanded by a regular KDE user..

* Remove "System Administration/Boot Manager(LILO)"(into "KAdmin") for the 
same reasons as "Linux Kernel". 

* Move "System Administration/Sony Vaio Laptop Hardware" to "Hardware".

* Remove "Desktop/Size & Orientation" - that one's too available in 
"Peripherals/Display". A NoDisplay=true for 3.2?

* Move "Spell Checker" to "Country & Accessibility".

* We distinguish between "KDE Components" and "System Administration" - KDE 
stuff in KDE Components and everything else in Sys Admin. The user can't see 
this difference and that's why these two has to be merged.

* The kcmshell call done by <left click desktop>->Configure Desktop should 
include monitor-hardware settings. 3.2 change?

* Merge "System Administration/user" account and "Internet Network/Email". Put 
it in security and privacy? (remove smtp setting)

* In the long run a merge of "Desktop" and "Appearance & Themes".

* "KDE Performance" is konqueror specific, AFAICT. It should be moved to 
konqueror.

* Merge "System administration/Font Installer" and "Appearance & Themes/Fonts"

---------------------- Miscellaneous -----------------------

* Somehow Sony Vaio and Laptop Battery and possible others must be made 
conditional, it makes no sense displaying those things on a system which does 
not have the relevant hardware. Wild suggestion: A plugin system in 
KPersonalizer where the plugins detects the relevant hardware and do 
NoDisplay=true on the relevant modules(but those checks may not fail or be 
uncertain - it will then create a lot of confusion). Preferably without GUI 
ofcourse.

* /*_A_*/ /*_lot_*/ of options in the different modules can be removed or 
merged(centralized) but that can wait and will generate a lot of noise. Those 
claiming less information is not faster and easier to parse than more 
information is just talking bullshit, IMHO. As part of this cleanup and 
merging of kcms, lessen the amount of options is essential.

* Then there's this "Local Network Chat", "File Sharing" and "MLDonkey" in 
"Internet & Network". Should some/all be moved to "KAdmin"?(and if not, isn't 
it then application specific?) Should it be in kde at all? I remember some of 
this(kchat) was discussed long ago but can't recall anything useful. I hardly 
know what the things is. Feel free to make some noise about it. I also wonder 
about this "Image Index" in "System Administration".

* I also think it's important to see and compare to how ArkLinux, SuSE, 
Mandrake etc does to KDE/KControl because it reveals some important opinions 
on how people don't want it. The day they leave it untouched is when we have 
succeeded..

* Remove "Internet & Network/Web Browser", William discusses it throughly - I 
agree. AFAICT, all the settings are Konqueror specific and shouldn't be in 
kcontrol. It reminds me of Microsoft's antitrust case(especially considering 
its generic wording - "Web Browser")... Any reason to keep it? 3.2 change?

* If the above proposals (roughly) play out well the remaining options in 
Internet & Network can be moved to System Administration. BTW, I think 
blurring the lines between root kcm's and regular's is ok, it's unavoidable. 
No matter where we put root-kcm's the user will have to use them and from the 
user's perspective it's illogical structuring having kcms in one place 
because they're root kcms.

* In the long run merge "KDE Components" with "System Administration".




Comments, suggestions, ideas, additions - highly welcome :)


Cheers!

		Frans















_______________________________________________
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]