Kernel Cousin KDE Issue #4 is Out

Aaron J. Seigo is back with another excellent edition of KC KDE. This week, read about Matthias Ettrich advocating the use of CORBA/ORBit as an alternative to ICE for DCOP interprocess communication, IMAP in KMail CVS, new KWin styles and themability improvements, kdeprint updates, offline surfing in Konqueror, and more. Read it all here.


Wouldn't it be a better idea to make KDE actualy start up faster rather than change the start-up splash screen? How does that fix the problem?

By John at Sun, 2001/04/01 - 6:00am

Well, of course it would be better to make KDE start up faster, and people are working towards that eventuality. However, a lot gets done at startup, therefore starting KDE does take some time. Period.

The problem remains however that many users see "Starting Window Manager", watch it take several seconds, and think "Wow. That KWin is SLOW!" when in reality several complex applications have started, not just kwin. Letting people know that all of this is going on can help users appreciate that it isn't slow, but rather a lot of processing is occuring. Some of that processing time is spent making the rest of the KDE experience faster, such as preloading KDE libs into memory.

By Aaron J. Seigo at Sun, 2001/04/01 - 6:00am

The particular problem in the reported case (which made a 950Mhz athlon start as slow as a 350mhz K6) was a configuration problem which stalled some startup code - I don't know whether the "solution" ever made it to the mailing list or just did not make it into "Kernel Cousin".

To give people an idea how long kde "should" take to start here are some times from my machine (450Mhz PIII, "warm caches"):
dcop : 0.5
kded : 2.3
kcminit : 0.4
wm started : 2.2
kdesktop: 2.0
kicker : 1.6
session: 0.1 (no program gets started)

If the relation between these stages is very different, you might want to take a close look at debug output to see if there is some problem.

If you look at the above numbers you see that it takes a lot longer than you'd want - but that the time is split very finely among a lot of different tasks, so that it is very difficult to "take a big axe" to some feature you don't want/need.

I spent a weekend looking for possible speedups and the only measurable thing I found was a faster heuristic for building hash tables in kbuildsycoca, which took out almost 1 second of startup time - at the cost of slightly worse hash characteristics.


By Martin Schenk at Sun, 2001/04/01 - 6:00am

I've been wondering about the startup times myself. This is the conclusion/suggestion that I came to. Since the job of a WM is to provide a UI for the user, the first thing the WM should do is give the user a working UI. Given the 9.1 second example above, it would make sence to have the wm load taking it's 2.2 seconds. No one should complain about that. After that everything else that should be loaded can be loaded in the background.

Sure, doing things this way may mean that the first application loaded may take an initial load-time performance hit, but by the time it's loaded, everything else will be too!

Now for a suggestion:
How about adding a scrolling buffered window that catches the stdout/stderr messages of the apps running in KDE, including kwm! This way, if I click on an icon and the program fails to run, I can just look in that window and see what happened instead of trying to go to tty12(on my system) and praying that the message didn't scroll off-screen yet.

By Arkain at Mon, 2001/04/02 - 5:00am

I agree, being in development myself we always have to deal with preceived speed of the app verses true speed. As a developer I understand that alot is taking place, but as a user I dont want to have to sit and wait.

I also like the idea of having a small window showing what is taking place in the background and think is would be useful if we had the ability to keep it up during the whole session instead of just start up....(I know there are ways to do this now....this is just a sugestion for user friendliness.

By jb3rry at Thu, 2001/04/05 - 5:00am

I have to disagree with you about giving a working UI first. Currently W2k will give you a working shell very quickly after you complete the login. As a naive user, I get control and launch my first app. Unfortunately the rest of the system libraries have not been loaded. Now there is contention for the disk, and I end waiting longer to use my app than if the system loaded its libraries up, and then launched my app.

And yes, I have actually ad-hoc tested this on my W2k box. I timed starting outlook from as soon as I get the shell and from waiting until the disk activity slows down and then starting outlook. I save several seconds by waiting.

By Jesse at Sat, 2001/04/07 - 5:00am

I'd love to see GNOME and KDE use the same core ipc mechanism. I'll think this would open up the current 'not invented here' trench war and really benefit both desktops.
What I've read from the list archive the arguments against it are a bit vague, and a bit closed minded.

Something to look forward to in KDE 3.0?

By Fredrik at Sun, 2001/04/01 - 6:00am

I too would like to see cooperation between the projects and I think that cooperation on the IPC level would be tremendous.

However, merely choosing to use ORBit does not a standard make. IMO we do not need a de facto standard that can be changed whenever one of the projects decides to alter course (and we all know that such a thing would NEVER happen, right? ;-)

What is needed for meaningful cooperation is an explicit and well defined standard so that inertia isn't the only thing keeping cooperation together.

That said, the arguments against using ORBit have been not close minded as much as pragmatic. The developers want to know what ORBit will gain us verses the amount of work it will be (and without a defined standard the percieved worth is less).

Of course, the developers are also concentrating right now on making KDE2 the best they can. There are a good number of open bugs remaining as well as features that needs adding or adjusting (and they are doing a great job of it, I might add =). Right now probably isn't the best time to go and change something so deep and at the core of the desktop.

By Aaron J. Seigo at Sun, 2001/04/01 - 6:00am

If you didn't know ORBit is a CORBA(2.2?) implimentation. CORBA is an open standard. If you would like to learn more about CORBA go to www.omg.org. The reasont that KDE decied not to use CORBA for IPC is becuase the developers where using the buggy bloated MICO implimentation, ORBit is getting alot of work and is becoming extremely fast and very light on recources, CORBA also add alot of flexibilty, like remote objects. One of the huge advantatges to using CORBA is that there could eventualy be a CORBA wrap to the Qt and KDE libs. Apps using GPL Qt would not have to be released under the GPL because they aren't linked to the libs, thus making the Qt libraries truly free to use anyway you want.

By robert at Thu, 2001/04/05 - 5:00am

While I appreciate you taking time to point me in the direction of some useful information, I am fully aware of what ORBit is as well as the history of CORBA in KDE.

That said, my problem is not with using CORBA itself, but in the creation of de facto standards as opposed to defined and agreed upon standards between the parties involved.

Additionally, I find the concept of end-running someone's licensing wishes by using something like CORBA wrappers to be lacking in ethical meritt.

By Aaron J. Seigo at Thu, 2001/04/05 - 5:00am

Did anyone try ACE/TAO instead of ORBit ?
Well ... TAO has some advantages I think.

By Chafik Moalem at Wed, 2001/04/04 - 5:00am

Is this another April Fool's joke ?

By Anonymous KDE User at Wed, 2001/04/04 - 5:00am

If it is they'd sure been cunning, the first post is dated march the 26th and has 16 follow-ups.

By Fredrik at Wed, 2001/04/04 - 5:00am

I agree completely. This merge would be a boon to application developers and desktop acceptance alike. I encourage all KDE developers to strongly debate the pros and cons of this proposal and then make a decision based on what is best for your users.

Best regards,


By David Joham at Sun, 2001/04/01 - 6:00am

Does anyone know what I need to install or configure in order to get Konqueror to use a GTK theme? I use GNOME (sorry!) but I like Konqueror as a browser and I also want a consistent look'n'feel to all my apps. I looked in the Konqueror settings dialogs but can't find anything (I use debian and the only KDE packages I have installed are Konqueror+dependencies).

What I'd *really* love is if KDE-based applications would automatically "notice" that they're actually running under GNOME and pick up the GTK theme if so. Then I'd like GNOME apps to do the same when running under KDE, but that's another complaint and not one anyone here can do anything about...

Thanks in advance,


By Stuart at Tue, 2001/04/03 - 5:00am

Try "K -> System -> Legacy theme importer" or run klegacyimport

By KDE User at Tue, 2001/04/03 - 5:00am