[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic