[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-14 2:44:51
Message-ID: 200401140344.51773.frans.englich () telia ! com
[Download RAW message or body]

On Friday 09 January 2004 21:36, Aaron J. Seigo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Friday 09 January 2004 09:06, Charles de Miramon wrote:
> > I think the idea of isolating the kcm code in a ad hoc directory for each
> > application is a good one. The more structured the cvs is, the easier it
> > is to somebody new to the code to find his way.
>
> agreed, but i'm wondering at what, if any, added complexity this will
> create in managing/coding kcms that share code / headers with the programs
> they are associated with. it also makes moving apps around more difficult
> in the future as they are framented into several pieces.

Yes, keeping all kcms in one dir have some drawbacks:

1) Sharing code is cumbersome - it means AM_CPPFLAGS="../../dir/". Similar for 
convenience libs.
2) Moving a piece of code means doing one extra move since the associated KCM 
is in another dir.

Doing the Makefile.am changes in order to share code is done once, and 
they are really small. Moving code is done rarely(two, three times per major 
release?), even more seldom it involves a kcm. Doing one extra move each 
time is not that much.
The extra work it means having the kcm's separated is not much AFAICT. If 
there is advantages with having them separated I think it needs further 
consideration.
Furthermore, I don't think kcms is moved much. Apps to and from kdenonbeta is 
one thing but the kcm(as they should) often represents functionality that is 
not tied to an actual application(although to physical code, like kwin).
(KCM's shouldn't be moved much. They represent /global/ settings and in that 
concept it really doesn't fit in that kcm's movies in and out as much as 
regular apps. I think this will get more clear and established as kcontrol 
development will get structured..)


> personally, i'd be 
> more inclined to see a structure like:
>
> <module>/<application-name>/kcm

And that would AFAICT, counteract the main purposes of my idea.

The point with throwing the all in KCMs is to change perspective on KControl 
and its kcm's - instead of saying "a kcm belongs to an app, and so be it" we 
loose the kcm from the implementation and focuses on the how the user 
percepts. If someone says "Hey, it would be better if option x in kcm b were 
in kcm a" that should be possible to do, and not hindered because of 
technical or emotional reasons. To put in another way: The kcm-kcm 
relationship is more important than the kcm-app.
IMHO, much of KDE's usability problems boils down to that we always looks from 
a developers perspective(and while on the subject, my belly button is just 
soo beautiful..). Decoupling the kcm's makes it possible to make usability 
decision which is not so tied to the underlaying implementation.

Navigation would also be just as hard as it is now, basically. If I look at 
the kcm's in kdebase/kcontrol tons of them do not belong to an app(there 
won't be any pretty path pattern). That's perhaps why they're all in 
kcontrol.. It also demands you know what "kded" "kwin" etc means. The entry 
barrier would not be lowered(and that is IMHO crucial).

Throwing them all in PKG/KCMs allows us to assign KCM maintainers for each 
package. Being a KCM Maintainer would be something honorable to put in your 
signature - it is not just an appendage for an app, it is quite big task with 
a big impact. We can assign cvs access to PKG/KCMs for a developer and that 
user can have a cozy feeling of "this is my pet project". Heck, it would even 
be hard to get a decision implemented without having each KDE developer 
objecting(since it involves "his"/"her" app) even though the KCM team has 
agreed on it.

I think my proposal can be reread(the top of this thread) and for each 
positive effect of it, you can ask yourself if it will work without the 
directory layout. I think this proposal, has the directory layout as a 
necessary dependency and can't live without it.


Cheers,

			Frans


_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]