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

List:       kde-core-devel
Subject:    Re: RFC: Changes to KControl for KDE 3.0
From:       Neil Stevens <neil () qualityassistant ! com>
Date:       2001-09-06 14:36:43
[Download RAW message or body]

Undeliverable, trying again...

On Wednesday September 05, 2001 11:20, Daniel Molkentin wrote:
> All modules should be called kcm<modulename>, for example the modules to
> set up the font module should be called "kcmfonts" instead of simply
> "fonts". The current way (mixing up both) is extremely confusing. The
> directory holding the config module should always be called
> kcm<modulename>. Otherwise we might end up in situations like the
> "display" directory which holds the "style" module.

Consistency is useful, but of course this is only needed if #2 is 
implemented.

> 2. Reorganization of  the directory structure:
> All modules should be hosted in a subdirectory of the according main
> application. However, I see that there are cases where modules span
> across multiple applications or are system-wide settings in which case
> we could still put them under kcontrol/ (I'd even prefer another subdir
> like "generic").

I'd like this as a step toward moving some of the non-core ones out of 
kdebase.

> 3. Changes for suid root applets
>
> The current behavior in terms of suid root applets is quite different.
> Either it shows a "disabled" (greyed-out) preview version or a message
> to press the "modify" button.
>
> I'd like to change this to a new approach: All modules should get the
> preview by default. Additionally, a notification box "Press modify to
> get access to the module" with a "do not show this message again"
> checkbox should be placed.

Again, consistency is useful.

> Another thing is that all modules that need root access (and therefore
> usally affect the whole system" should move to the "system" cathegory.
> This would for example involve to split off the LISa configuration from
> the current LAN Browsing module and put the LISa module to "system" (I
> just got the 3rd bug report about that from people that think that the
> current approach is broken, I support that btw).

It seems to me that this is a case of presenting UI as it is implemented, 
rather than how the user model of it is.  If a user wants to change 
setting X, he'll go look where things similar to X are.  He won't first 
think "Does this setting require root?" as he may not even know in advance 
whether it does.

-- 
Neil Stevens
neil@qualityassistant.com

Don't think of a bug as a problem.  Think of it as a call to action.

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