Kernel Traffic
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Cousin KDE #27 For 30�Nov�2001

Editor: Aaron J. Seigo

By Aaron J. Seigo �and� Juergen Appel

Table Of Contents


Welcome to KC KDE! While we continue the coverage of the march towards KDE3 this week, there is more than just coding and compiling happening within the KDE community these days. Since KDE2 was launched the amount of KDE-related information on the 'Net has proliferated with impressive momentum. As the community around KDE grows, so does the number of web sites dedicated to tracking, cataloguing and discussing various aspects of the KDE project..

This week two more web sites join the parade. intends to be a clearinghouse for all matters of interest to those running KDE on FreeBSD. is a site dedicated to the development and showcasing of the KDE printing facilities that truly blossomed during the KDE2 development cycle. It is great to see the user community showing such signs of growth and health.

We hope that you enjoy this week's summaries and happy hacking!

1. Problems with Qt 2.3.2

13�Nov�2001�-�21�Nov�2001 (22 posts) Archive Link: "Qt 2.3.2 and KDE_2_2_BRANCH"

Summary By Aaron J. Seigo

Topics: Building KDE, Qt

People: Lars Knoll

After installing Qt 2.3.2 and noticing some quirks, Thorsten Schnebeck asked the kde-devel list about it. Lars Knoll answered Thorsten's question saying, "The basic problem was, that kglobalaccel had a really nasty bug, that showed up when we changed the way popups are handled in 2.3.2 a bit. popups grab the keyboard (that's the only way to ensure proper behaviour), but kglobalaccel ungrabbed them again. After that they wouldn't work correctly anymore. One of the problems is, that KDE does a lot of X11 magic in some places, and things might break, when Qt changes their internal X11 event handling a little. That's one of the reasons we should try not to use too many direct X11 calls in KDE." Elsewhere Lars noted, " The problem/fix should be completely independent of config files. Just make sure you're using the lates kdelibs/kdecore/kglobalaccel.cpp together with Qt-2.3.2."

2. Desktop Icons: Be Gone! (Optionally)

14�Nov�2001�-�22�Nov�2001 (5 posts) Archive Link: "New & Improved in KDE 3.0!"

Summary By Aaron J. Seigo

Topics: Icons, KDE 3

People: Waldo Bastian

"Does your desktop look like an unorganized mess? Do you have thousands of files on your desktop and can't find the right one? Do you long for the days when you could have xroaches under your windows?" asked Waldo Bastian, sounding much like a marketing pitch-man, " Despair no longer! Thanks to an incredible new technology KDE 3.0 will come with a revlutionary new feature that allows you to turn off those pesky icons on your desktop! You can impress your boss with your tidy desktop! You can have endless fun with programs like xroach and xsnow!"

And there was great rejoicing among those who despise desktop icons.

3. KAccel Gets Attention

16�Nov�2001�-�22�Nov�2001 (36 posts) Archive Link: "Heads up: new KAccel classes"

Summary By Aaron J. Seigo

Topics: Keybindings, KDE 3

People: Ellis Whitehead,�Waldo Bastian

As part of the ongoing cleanup and refactoring of the KDE libraries for 3.0, Ellis Whitehead turned his attention to the KAccel classes. Ellis announced the introduction of his work to CVS saying, "I'm committing rewritten KAccel & KGlobalAccel classes. Most custom global accel keys will be lost due to renaming of actions. Some programs outside of kdelibs and kdebase will require minor modifications, such as adding #includes which are no longer included in kaccel.h and kstdaccel.h. I've made the necessary mods to kdenetwork, but I have to run out for a few hours, so I'll commit them when I get back."

As with any major change of this sort, it was heavily reviewed and people quickly reported challenges with the new classes. Thomas Zander wanted to know if the loss of key bindings only applied to those following CVS, or if it would affect those upgrading from KDE2. Ellis replied, "as it is now, users moving from KDE2.x to KDE3.0 _will_ loose most custom key binding -- more specifically, the bindings will revert to their defaults. If we're going to try to preserve these settings across releases, it might not be a bad idea to perform the appropriate conversions in the kdeglobals resource file once on first startup of 3.0. Is there any mechanism for this sort of thing already in place?" Waldo Bastian was quick to answer Ellis' question saying, "see kdelibs/kconf_update. Basically you just need to install a file that describes the changes to be made and possibly a small perl script that does the conversions. There is README, feel free toask if you any questions or feature requests"

Dirk Mueller also pointed out that the rewritten classes were source incompatible with those that they were replacing. Ellis explained his decisions to break source compatibility saying, " There are three cases where it does this, and two of them are valid, the other I'm working on right now (since I hadn't encountered it before).

  1. some applications will have to #include "kstdaccel.h" or another include file that is no longer #included from kstdaction.h or kaccel.h
  2. applications which used KAccel::stringToKey() or related functions will now have to used KKeySequence instead.
  3. this is the big and invalid one, I'm afraid: insertItem() and connectItem() aren't source compatible. I'll commit the fix ASAP.

Several of the remaining issues with the new KAccel classes were also taken care of by Ellis since the initial announcement of their availability.

4. Dialogs That Steal Focus: Be Gone!

23�Nov�2001�-�24�Nov�2001 (6 posts) Subject: "Passive message popup class"

Summary By Aaron J. Seigo

Topics: UI

People: Richard Moore,�Adriaan de Groot

Ever been annoyed by a program popping up a dialog box right in the middle of your work causing you to lose keystrokes or concentration? Those days may be numbered if Richard Moore has a say in the matter. Richard wrote in to both the kde-core-devel and kde-look lists saying, " As part of my plan to improve the way KDE apps interact with the task manager, I've just finished a passive popup class that lets you display a message next to the taskbar icon. The popup does not interupt the user (hence the name 'passive'). The implementation uses the standard icon geometry properties from the WM specs, so it should work with any WM and taskbar. I've attached, the code, a demo app, the docs and a small piccy. I'd like to see this (and hopefully some other related tools) in the 3.0 api. Any comments?"

Adriaan de Groot asked, " I take it this works with systray applications as well?" and added, " How about extending it that you can have one passive log window that keeps some history? Although, that may be a job for the application more than for the popup itself." Richard replied that he would add support for systray apps and that extending KNotify to use the new classes would probably be the way to go to get passive logs and other fancy features.

Elsewhere in the thread, Richard mentioned he had added support for messages to appear in the title bar of a window, or in the application's icon. The chances of this work appearing in KDE 3.0 may be slim, but Richard is continuing to work on this functionality with an eye towards making KNotify a much more useful KDE subsystem.

5. .desktop Files and Application Names

24�Nov�2001�-�27�Nov�2001 (31 posts) Archive Link: "About naming of apps in .desktop files"

Summary By Aaron J. Seigo

Topics: Applications

People: Christoph Cullman,�Richard Bos,�Mariusz Pekala

Like the hero in a spy movie, certain topics just never seem to die. Christoph Cullman reawakened one of these sleeping giants when he said, " just want to ask, if it woudn'T be better to write done into the desktop files translation of the name something like "original appname" - "short translation". The endusers end up at the moment with for example the k-menu displaying entries like "Mediaplayer", "DVI Viewer" ..... Wouldn't it be much better to have entries like "KDVI - DVI Viewer", "Noatun - Media Player" and so on ?" Richard Bos offered the dissenting view saying, "But then swapped like: DVI Viewer (kdvi), Media Player (noatun) as they listed alphabetically it would group the same application automatically"

As the thread meandered on just about every variation imaginable was put forward with the pros and cons of each being examined. But actual general agreement and resolution seemed distant as it is a matter of personal opinion, preference and experience. Realizing this, Mariusz Pekala suggested the following:

different users have different preferences with the order - konqueror (Web browser) OR Web browser (konqueror) OR konqueror OR Web browser. So, introduce a format string that the user will be able to choose the way he likes to see the names: let the "%n (%d)" stand for "file-name (Descriptive description)"

About translations: For example, I don't like too much translations from English to Polish - the Polish language produces long sentences (other languages produce even longer, as seen in a lot of .desktop files) and I have small monitor :-) Others may like translations, so give them another options for this format-string:

...and set a reasonable default. Most users will probably like this one: "%C (%n)"

There was general agreement on this concept and the thread stopped quickly thereafter. Perhaps this will even make its way into KDE3. At the very least it should prove to be a final answer for this recurring topic.

6. KEdit Class Improvements

25�Nov�2001�-�27�Nov�2001 (19 posts) Archive Link: "[patch] New KEdit ready, please review"

Summary By Aaron J. Seigo

People: Mickael Marchand,�Waldo Bastian

Mickael Marchand completed support in KDE for the new KEdit classes and reported his success saying, " i have ended most important patchs for KDE's apps, New KEdit/KEdFind/KEdReplace implies modification in khtml, kmail, knode, and kedit ;p (patchs are all ready) These patches moves our old KEdit:QMultiLineEdit to a QTextEditor (as QMultiLineEdit is obsolete now)and adds KEdFind/KEdReplace dialogs from KOffice (adding internal RegExps support and more options)"

While attempting to add KRegExpEditor support into the mix Mickael ran into problems. Several suggestions were offered with varying degrees of success and ugliness. After some discussion Waldo Bastian suggested:

I would leave KEdit/keditcl as is and create a new directory libktextedit that implements a edit-widget that dynamically loads the user's preferred KTextEditor part (that's basically a single factory method) and a KSimpleEdit that implements a KTextEditor part based on QTextEdit (you could start with a copy of keditcl for that)

I guess this factory method is simple enough to be added to libkpart. So libktextedit would only contain KSimpleEdit which builds into something like libksimpleedit, the default part for this factory method.

We can then mark KEdit/keditcl as obsolete and schedule it's removal for KDE 4 or whenever Qt decides to drop QMultiLineEdit completely.

Mickael agreed with Waldo saying, " developers should be adviced to switch their KEdit to the KTextEditor then we will have a common text editor interface everywhere"

7. aRts Linux Kernel Module

26�Nov�2001 (4 posts) Archive Link: "aRts-OSS 0.1.0"

Summary By Aaron J. Seigo

Topics: aRts

People: Charles Samuels,�Richard Stevens

Multimedia on KDE has been moving forward in an evolutionary way over that past few years. Steady improvements have been seen in MCOP, aRts and the KDE media applications. The latest step in this evolution was announced by Charles Samuels:

Announcing the release of aRts-OSS 0.1.0. This is a technology preview of aRts-OSS, a kernel-level aRts driver. Giving all Linux machines the capability of multiple OSS audio applications to play through the aRts soundsystem without an LD_PRELOAD emulation layer. This kernel module behaves like a normal OSS driver to all applications.

This does not replace either OSS or arts

OSS application -> *aRts-OSS* -> artsd -> Sound card (OSS or Alsa)

Download and more information is available at the site:

The usual request for more details was made and Richard Stevens said:

First, usually only one application can access the oss device for playing sound. Arts is capable of mixing the soundoutput of multiple sources (applications). You can ie. hear the incoming message on ICQ while listening to mp3s. There is a way to have non arts enabled applications (wich can only access oss devices) emit sound through arts. You can do artsdsp appxyz and appxyz can access some virtual oss device for output. In fact it's not accessing it but a library intercepts the oss stuff and pipes it to arts. Maybe some conversion takes place underway. I wouldn't know. The library is loaded with LD_PRELOAD. That means as far as I understood it, load the library before the application links to the library it uses. Having something like that in the kernel would enable virtual dsp devices and you wouldn't have to use the artsdsp app or the LD_PRELOAD mechanism. Sound is now arriving from the application (userland) to the kernel (new module) back to userland (artsd) back to the kernel (artsd accesses the real oss device) right through your soundcard out to your speakers.

Charles confirmed that this is indeed how aRts-OSS works and added, " All this does is take audio from kernelspace and make it available to user space. Then there's another app (arts-kserv) that grabs the audio from the kernel and sends it to aRts."

8. New KDE Printing Website

2�Dec�2001 (1 post) Archive Link: "[kde-promo] [ANNOUNCE]:, KDEPrint mailing list"

Summary By Juergen Appel

Topics: Printing, Promotion, New Website

People: Chris Howells

Chris Howells announced that there is a new webpage available,
"There's quite a bit of material on the site, including FAQs, documentation, and screenshots of the new KDEPrint framework in KDE 3. There is also a new KDEPrint mailing list. Subscribe at, and post to the list using the address"

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.