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

List:       kde-usability
Subject:    Re: Summoning KControl development - Will it work? Mesa wonders
From:       Frans Englich <frans.englich () telia ! com>
Date:       2004-01-08 23:24:08
Message-ID: 200401090024.08108.frans.englich () telia ! com
[Download RAW message or body]

On Thursday 08 January 2004 01:23, Frans Englich wrote:

A small update:

It could be possible to interpret the proposal as the usability team "robs" 
the kcm's(which someone have written and owns). It should not be seen that 
way -  the decision taking and the physical locations have been centralized, 
nothing else. Everyone is of course welcome to participate and provide input.

Another advantage of this idea is of diplomatic art: It allows us to address 
our usability problems(which are political tense and often flamebait'ish) in 
a generic way. The guidelines we agree on, and put in the doc, is general and 
does not "hit" on specific issues explicitly. I think, that when (and if) 
this proposal is established a lot of usability decisions can be taken with 
much less noise. Much like (a scary :) big amount of fixes gets done with the 
motivation "to conform to UI Guidelines". 
It wouldn't surprise me if documentation corresponds to the benevolent 
dictator in democratic ruled projects.

Attached is a diff of an update to KCM_CONVENTIONS

Cheers,

			Frans




["kcm_conv_update.diff" (text/x-diff)]

--- KCM_CONVENTIONS.orig	2004-01-08 20:18:57.000000000 +0100
+++ KCM_CONVENTIONS	2004-01-08 21:55:13.000000000 +0100
@@ -1,4 +1,4 @@
-Copyright (c)  2004  Frans Englich <frans.englich@telia.com>.
+Copyright (C)  2004  Frans Englich <frans.englich@telia.com>.
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.2
 or any later version published by the Free Software Foundation;
@@ -6,6 +6,9 @@
 Texts.  A copy of the license is included in the section entitled "GNU
 Free Documentation License".
 
+PLEASE NOTE: This is a draft so don't jump in your chair if something 
+is unreasonable. But please tell the authors(kde-usability) that they are
+unreasonable. Otherwise you will really have to jump in your chair.
 
 This file describes the organisational layout and file structure for KDE's 
 KCMs(KControl Modules) as well as design recommendations and conventions 
@@ -50,13 +53,42 @@
 * The name of the desktop file is the KCM's library name prefixed 
 with "kcm_". For example "kcm_kmix.desktop".
 
-* If the KCM has an icon specific for the KCM its basename should be 
+* If the KCM has an specific icon its basename should be 
 the same as the library name.
 
-* The main source file and its header should be named main.cpp and 
-main.h, respectively.
+* The main source file(containing the KCModule subclass) and its header 
+shall be named "main.cpp" and "main.h", respectively.
 
+* The name of the .kcfg file shall be the name of the library name.
+For example, "kmix.kcfg".
 
+* The name of the .kcfgc file shall be the name of the library name.
+For example, "kmix.kcfgc".
+
+--- Broad Design Hints ---
+Keep the following in mind when adding or modifying existing KCMs:
+
+* The content of an KCM may not be, from the user's point of view, 
+application specific. KControl's purpose is to in a central place 
+provide configuration for functionality which is global for KDE. 
+Keeping application specific configuration in KControl simply makes 
+it too big and bloated(people have already tried this). Technically, 
+the functionality the KCM represents can be an application or isolated 
+and separated but that is irrelevant - it is about how the users percepts 
+and sees it, not how it is implemented.
+
+* We don't want configuration. In a perfect world the default settings 
+fits everyone and the hardware Just Works. This is not the case so 
+we have KControl. 
+But that is no reason to have unnecessary options and 
+bloat in a KCM. For every configuration option you could ask: Is this 
+option really, really necessary? Does a significant part of KDE's users need 
+it? Was it implemented because it was a "cool" feature and fun to do? Does 
+other KCMs have similar options which could be combined into a global 
+one? Could the implementation be changed so the user does not have to take 
+the (configuration) decision? 
+The one with the simplest, and smallest amount of config options wins. But 
+sustained functionality is a must, of course.
 
 --- A Valid KCM ---
 In order for an KCM to be good and valid it must conform to:
@@ -68,15 +100,18 @@
 2) KDE User Interface Guidelines. Please see:
 http://developer.kde.org/documentation/standards/kde/style/basics/index.html
 
-3) the conventions and recommendations in this file.
+3) The conventions and recommendations in this file.
+
+4) A valid .desktop file. If you are not 110% sure of what you're doing, 
+validate with freedesktop's desktop-file-utils:
+http://www.freedesktop.org/Software/desktop-file-utils
 
 If the KCM does not conform, it is considered a broken KCM.
 
 These guidelines exist in order to make the KCMs look consistent, 
 be pleasent for the user and blend with the rest of KDE as well as 
 ensuring KDE stay out of legal trouble. It also makes life easier 
-for use developers.
-
+for developers.
 
 
 --- Name Recommendations ---
@@ -86,24 +121,25 @@
 consistency between the modules:
 
 * Try to keep the phrase short. Shorter phrases is easier and
-fast to interpret and give better options for designing the layout. 
+faster to interpret and give better options for designing the layout. 
 From a esthetically perspective it also looks cleaner and simpler.
 
 * Avoid complex phrases involving backslashes("/)" and paranteses
-for the same reasons as above. 
+for the same reasons as above. It also makes translation more 
+difficult.
 
 * Avoid including words like "Management" and "Configuration" etc. 
-since it is abundant - KControl is all about that which the user 
+since it is abundant - KControl is all about that, which the user 
 already is aware of. Furthermore, such terms does not inform the 
 user about what Your module contains, except that it is for 
 configuration or management(and that is already clear since it is 
 in KControl).
 
 * KControl as the rest of KDE targets a wide audience where a 
-significant part of the users does not have technical expertise. 
-In order to have a compelling interface it is important to avoid 
-technical and "scary" terms. Words used should an average user be 
-able to understand.
+majority(to say the least) of the users does not have technical 
+expertise. In order to have a compelling interface it is important 
+to avoid technical and "scary" terms. Words used should an average 
+user be able to understand.
 
 The above name recommendations is guidelines and must not be 
 strictly followed. If the name demands to be longer than average
@@ -125,16 +161,22 @@
 instead of handwritten ones because 1) It allows people without 
 C++ experience to modify GUIs; 2) It is safer since it is not 
 manually written code; 3) It allows more obtrusive changes to be 
-done in code freezes; and 4) Usually more efficient and faster 
-code.
+done in code freezes; 4) Faster development; and 5) Usually 
+more efficient and faster code.
 
 * KConfigXT framework instead of handcrafted configuration code
-The rationalis is similar to the above with notable addition: 
-it saves disc space on installed clients.
+The rationalis is similar to the above with notable addition: It 
+saves disk space on installed clients.
 
 These recommendations exists in order to make development faster 
-and easier resulting in better and bugfree code but neither these 
+and easier, resulting in better and bugfree code but neither these 
 recommendations should be followed blindly. For example, if a 
-handcrafted GUI for some rational reason(which is different from 
-"preferred by developer") that should be chosen. 
+handcrafted GUI for some rational reason is preferred(which is 
+different from "preferred by developer") that should be chosen. 
+
+--- Breif History ---
+This structuring of KCMs and the policies were started around the 
+release of KDE 3.1 since the KControl/KCM situation had been unbearable 
+since KDE 3.0 and some fresh thinking was needed.
+
 


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