Guidance in KDE Admin

Leo Savernik l.savernik at
Sun Mar 30 18:37:56 BST 2008

Am Freitag, 28. März 2008 schrieb Aaron J. Seigo:
> On Friday 28 March 2008, Leo Savernik wrote:
> > Am Donnerstag, 27. März 2008 schrieb Sebastian Kuegler:
> > > On Thursday 27 March 2008 20:51:11 Leo Savernik wrote:
> > > > So I'm not convinced that the benefits of introducing python KDE core
> > > > applications outweigh the disadvantages.
> > >
> > > What's your definition of a core application? We might all agree ...
> >
> > Everything that is released with a new KDE release.
> that's a very broad brush stroke.

Ok, I'm open to narrow the scope, but there should be a scope.
> as a firm example (i hate arguements of the vague =): is khexedit, er,
> oktetta really a core app?

I'd say khexedit isn't a well fitting example as a hex editor is expected to 
be lean and fast itself. khexedit isn't very fast, so it already feels as if 
it were scripted. I haven't tried okteta yet.

> would it make one lick of difference if it were 
> writting in python, ruby or c++? [...] i really think leaving it up to the 
> will mean we get more apps, quicker and with fewer bugs.
> for this reason, i think we lose the benefits we would otherwise stand to
> gain by painting too broadly here.
> my proposal would be to define kdelibs, kdebase-runtime/apps/workspace
> essentials as core apps that should be kept rationally lean and mean, with
> the rest of the apps being dealt with on a case-by-case basis using common
> sense.

I think that's too narrow a scope and like to extend it by kdegraphics. 
Rationale: Apps like gwenview and okular are perceived as lightweight and 
should behave so. This also encompasses their memory footprint. Ksnapshot 
should be fast, too (here startup time being most important which can't be 
sensibly accelerated by scripting).

I'd also like to extend the scope by kdenetwork. Rationale: People relying on 
kppp are likely not to have access to the latest and greatest hardware.

I'd also like to extend the scope by kdemultimedia. Rationale: We need a lean 
media player that loads very fast.

Why I'm also picky about kdeadmin is that basic administrative tasks should be 
able to be performed under memory and speed constrained environments as well. 
That's why guidance may not fit into kdeadmin.
> p.s. the eee pc is a bad example for memory constrinats; it comes with half
> a GB of main memory (and up). there are other interesting potential target
> devices that come with far less, such as the n800 which comes with as
> "little" as 64MB, so your point about paying attention to memory
> consumption is imho valid. that said, the olpc with 256MB of main memory
> uses python extensively. *shrug*

KDE *could* bare an additional scripting language, the question is where to 
draw the line. At least KDE 4 should retain the potential to be usable on an 
olpc in its default configuration, that could be marketed as a great success 
for KDE 4.


More information about the kde-core-devel mailing list