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

List:       kde-debian
Subject:    Framework vs configurability Was: Control Center or separate
From:       Claes Holmerson <claes () it-slav ! net>
Date:       2004-01-04 0:28:35
Message-ID: Pine.BSO.4.53.0401040033360.3549 () vakttornet ! mynet
[Download RAW message or body]


On Sun, 4 Jan 2004, Dominique Devriese wrote:
> Yes, but I really don't see why this cannot be done within KControl,
> and with the current mechanisms ( put descriptions in the .desktop
> files describing the KCM, remove or add .desktop files to determine
> what KCM's to show ).

A disclaimer first: I am not a KDE developer and am not a proficient C++
programmer. I think I have a decent grasp of some KDE technologies on a
higher level, and good knowledge of some other software technologies,
like java and web technologies. What follows below is less about the
control center, and more about the rationale for my questions and
suggestions. It is also less about debian, but more about the enterprise
aspect.

Of course it is possible to do within KControl. My thoughts are not so
much about what is possible to accomplish, but how it can be
accomplished.

My personal experience of working with enterprise customers is that
demands vary a lot and are difficult to predict. To meet these demands
I think there are basically two strategies:

- either develop a very configurable product, with lots of configuration
options, knobs to turn and settings to set.

- or offer a more generic framework, together with building blocks that
can be used to put things together in different ways. This is more work
for the customer, but also gives him more control to customize in ways
that he would like.

The first example is basically what KDE is today. It is also the
second example, but only if you are a skilled C++ programmer. Scripting
bindings, while they exist for KDE, are not part of the KDE release (as I
understand it), and that makes them harder to work with, and customers may
wonder if they dare commit to them.

My suggestions are not so much about how to improve the official, bundled
control center, as to find out how things can be put together in other
ways, when customers want to customize parts of KDE in ways that have
not been predicted. Many more people are knowledgable about scripting
languages and html, and as I see it Konqueror is a great platform to do
that with. It bascially has most things for this already as it
seems.

If I could give two pieces of advice (whatever that is worth) to the KDE
project, they would be:

- make python and other scripting bindings offically part of KDE releases

- support web-based technologies within the desktop. My questions
regarding kpart embedding and links to .desktop files are related to this.
With this I mean: scripts together with HTML that interacts with things in
the desktop. HTML can often to prefer because it allows a more
descriptions and explanations together with the data it presents.
Application labels and menus often become quite short and cryptic, while
there is more space for explanations or even documentation in web pages.
This also increases the pool of people who can contribute. While building
a word processor with web technologies is stupid, I think many kinds of
configuration tools could be well implemented this way. And if Konqueror
with some glue could integrate these two, you would get the best of two
worlds.

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