structure of kde cvs modules, was Re: libkipi in kdesupport

[Cristian Tibirna]

On Thursday 18 March 2004 11:10, Stephan Kulow wrote:
> On Thursday 18 March 2004 14:45, Waldo Bastian wrote:
> > On Thu March 18 2004 13:55, Cristian Tibirna wrote:
> > > Well, _this_ is the central issue. IMO, all applications developed with
> > > KDE framework and obeying KDE guidelines deserve to be _equally_ part
> > > of the KDE application collection. Right now, this is not so because of
> > > the perceived stratification in "apps resident in KDE's official CVS"
> > > and "others". IMHO, we would become much stronger if we would fix this.
> >
> > I very much agree.
>
> Then it will be "apps released together with KDE libs" and "others"? What's
> the practical difference?

The practical difference is that the apps that are(/will be?) released 
together with KDE libs are(/will be?) essential for a functional desktop (and 
here is all the weak point of this side of the argument, I come back to this 
below). Not essential == "others".

Now, I said, here comes my understanding of the weak point: a) what are the 
criteria to decide when an app is essential for the functional desktop b) who 
picks those criteria and finally c) how to/who will enforce the criteria.

I give MHO/vision on this (as an example). Essential apps can be considered:
- kcontrol + a few selected kcms (well, all minus the application and kcms)
- kdesktop
- kicker + a few selected modules (pager, clock, systray)
- kwin
- knotify (+ arts)
- a minimal image viewer (offering part functionalities too)
- an editor (probably kate, as it offers the kwrite skin)
- the keyboard switcher
- the sound mixer
- konqueror (hmmm...)

Now, spelling out the criteria... hard task. Well, perhaps defining very 
basic/indispensable functionalities, that are so basic that's not sensible to 
have 10 ways of implementing them. E.g. how many mixers does one need? (yeah, 
current Linux OS situation is ridiculous, I have at least 6 mixers installed, 
cli-based, X-based, toolkit-gnostic, toolkit-agnostic etc.). We can all agree 
that (even taking a 10k messages thread to detail its design) we can come 
with a final say, its proper/clean implementation and be done. 

Of course, casting such a definition is calling for trouble. E.g., how would 
kwin fit into this? Or what do we do with the 3-4 kcontrol rewrites in the 
3.X series? Go on, flame/speak/philosophate (merriam-webster pay-for 
definition ;-)


I must try to make myself clear. I hesitated a lot before getting involved in 
this discussion. I am under the impression that I don't have a 100% solid 
opinion. I know that there are a lot of disadvantages and a lot of advantages 
with both the current and the new proposed way of framing things. But I can't 
make my mind if a new way would be profitable (in terms of augmenting KDE 
_world's_ (as opposed to project's) whole quality and perception).

The thing that mostly makes me disturbing this list over and over again is my 
perception (subjective, it's understood) that we fail to put into light all 
the (both quantitatively and qualitatively) huge effort that goes on in 
modern application development in the KDE and KDE-related world.

I'd rather have us boost up our efforts (and attracting a few more talented 
web designers) for creating an (even more) "official" architecture similar to 
today's kde-apps.org and perhaps have binary packages creation sponsored by 
distributors but centralized on this "app portal" (I hate this word). This 
would IMHO help promoting much more applications on an equal basis. 
<daydream> Who knows, maybe one day we could have an install-on-demand 
service... </daydream>

Hey, thanks for listening, again (and I promise I try to refrain myself from 
writing endlessly ;-)


-- 
Cristian Tibirna
KDE developer .. tibirna at kde.org .. http://www.kde.org