KDE Traffic #39 For 18�Jun�2002

Editor: Juergen Appel

By Aaron J. Seigo �and� Juergen Appel

Table Of Contents


Welcome to KC KDE! Scores are in everyone's mouth at these times, on the coding front, the green-yellow team scored recently 14 scrolls and is followed by team red with 11 1/2 scrolls. To see the current state take a look here (http://developer.kde.org/development-versions/kde-3.1-features.html) and use your mouse wheel to scroll the page up. Team green-yellow equaled the score a week a go. Congratulations.

Besides this, roughly in one week KDE 3.0.2 will be ready for download, approximately at the same time the the KOffice development will be ready to release the second beta release (http://developer.kde.org/development-versions/koffice-1.2-release-plan.html) of the upcoming KOffice 1.2 as the feature freeze was on June 10th for stablizing this beta release, afterwards it will be open for commits again. As soon as it is out, feel free to test and file bug reports, if any.

We are aware of a the non-working archive links, they are caused by an insuffiecient compiler, it will be hopefully fixed when it's predecessor is released. Meanwhile you can run into the problem in four different languages, as the French translation team is back, so is the Spanish. Kudos to the translators (http://www.appel-systems.de/jay/kckdestaff.html) !

1. Kicker Xinerama Support

4�Jun�2002�-�6�Jun�2002 (4 posts) Archive Link: "Kicker Xinerama support"

Summary By Aaron J. Seigo

Topics: Kicker, Look and Feel

People: Kevin Puetzk

Kicker has seen quite a bit of "finishing touches" development thus far in the KDE3 series. This sort of development is important, especially for components which are as central to the desktop experience as the panel is. One area that Kicker has been lacking in is Xinerama support. In an aim to fix this Kevin Puetzk said, " The attached patch provides at least the beginnings of real Xinerama support for kicker placement. It allows the user to drag&drop the panel along any edge of any monitor, saves/restores panel placement correctly, and prevents panels from spanning across multiple screens. " Kevin noted the bugs he was aware of and asked for Xinerama users with unique configurations to test the patch. Shortly thereafter Kevin posted a second patch that addressed all the known bugs and committed it to CVS.

2. KDE/GNOME Interoperability

31�May�2002�-�4�Jun�2002 (35 posts) Archive Link: "GNOME/KDE interoperability hothouse"

Summary By Aaron J. Seigo

Topics: KDE and Gnome, Meeting

People: Jim Kingdon

Everyone benefits from interoperability between the various UNIX desktops, and efforts continue to work towards that goal. Jim Kingdon of the Free Standards Group cross-posted to the kde-core-devel, gnome-hackers and xdg-list lists with the announcement of a KDE/GNOME interoperability hothouse at LinuxWorld in San Francisco this August, saying:

There are various pieces to put together if this is going to happen, but at the moment, the big one is figuring out who can make it and what they would try to get done there.

On the question of who, I'm accepting indications of interest. There are lots of considerations here, such as trying to get people who can make decisions about the relevant bits of code, matching the people with the tasks, balancing GNOME and KDE (and others like ROX as relevant), and more. But I'm willing to start with: Who would find this fun? Who sees something here they'd like to work on?

On the question of what to work on, a few ideas are:

We think we'll probably find someone from XFree86 to serve as moderator. This might come in handy if X knowledge is involved, and in general seems like a Good Thing.


Follow ups to me or to the list(s) (the former if in doubt; this is sent to 3 lists). Flames definitely to me :-). I suppose it goes without saying, but there isn't much time between now and August, so we need to act quickly if we are going to make this happen.

Alan Cox raised the issue of non-American software developers meeting in the United States, which spawned a long thread about the relative merits of various locations for conferences. Several people did confirm their attendance, so it will be interesting to see what emerges from this event.

3. KDE 3.1 Release Schedule

2�Jun�2002�-�4�Jun�2002 (50 posts) Archive Link: "KDE 3.1 release schedule draft"

Summary By Aaron J. Seigo

Topics: Release Schedule, KDE 3.1

People: Dirk Mueller,�Thomas Diehl

With 3.0.1 released many people were waiting with baited breath for the 3.1 release schedule. Dirk Mueller, the release maintainer for KDE3, obliged saying:

I've put a 3.1 release schedule draft online at http://developer.kde.org/development-versions/kde-3.1-release-plan.html (http://developer.kde.org/development-versions/kde-3.1-release-plan.html)

The feature plan (!) freeze is rather soon, but given that the document got quite well maintained, I don't consider it to be a big problem. Although many of the entries are already in the green and yellow section, there is still a huge "red" TODO list. In my opinion there is not enough time to implement them all, even if we plan KDE 3.1 for early next year, so we have to cut it somewhere.

According to the current draft there are about 7 weeks left for implementing the "agreed on" features on the feature plan, and another 6 weeks bugfixing only. I suggest that this freeze period will be more strictly handled compared to the 3.0 release, which deliberately had a rather soft policy.

I know this schedule is rather tight, but in case, we can always slip it by for 2-3 weeks by adding another release candidate (or making the rc1 one a "public" one with 3-4 weeks time for feedback). I decided against "hardcoding" this already into the current draft for obvious reasons though.

Note dear translators: the i18n string freeze means changes by developers to i18n string changes. translators are always allowed to adjust stuff or to commit their translations. You're in no way affected by the freezes.

Thomas Diehl, KDE translation guru, expressed concern over the tight schedule for the translation teams saying, " Together with KOffice and vague plannings on 3.0.2 this means that translators (and a lot of other people) have to meet 3 release dates during the main vacation time in many countries: KOffice in July, 3.1 in August (if we keep early September), and 3.0.2 somewhere in between. If I remember correctly from past years, activity esp. in August is minimal. And although the releases are not of equal importance (esp. 3.0.2) this seems a bit much to me. Any special reason why we must have 3.1 this early? I mean 3.0 went just out the door, and 5 months (between April and September) does not look like very much time to me for adding a whole lot of new functions and test them properly as I think was planned for the first major release after 3.0." After some discussion to clarify what the challenges were exactly, Dirk extended the release cycle by 7 weeks and Thomas agreed that this would work well.

The rest of the thread centered around people who had to push their planned features to 3.2 and others who were concerned that with such a tight schedule there wouldn't be as many new features as usual. As a response to these concerns Dirk said, "I don't want to point out specific entries in the feature list now, but some of them really look(ed) like they were planned for KDE 4.0 and not for a KDE 3.1 release. Given that our buglist grows by a few hundred new open bugs per month, I don't think we should majorly focus on new features. "

At the same time, with 3.1 slated to ship with video support, the new Keramik style, three new games, tabbed browsing and a slew of other improvements there is little doubt that 3.1 will be yet another exciting release.

4. KDE on HP/UX?

1�Jun�2002�-�3�Jun�2002 (7 posts) Archive Link: "SUCCESS: aRts works on HPUX"

Summary By Aaron J. Seigo

Topics: Operating Systems, HP/UX

People: Ravikiran Rajagopal,�Michael Matz,�Allan Sandfeld Jensen

Those who work on HP/UX systems take heart! Ravikiran Rajagopal reported successfully building aRts on that platform saying, " In case anyone is interested, I have a working copy of (multithreaded!) aRts 3.0 installed on my HPUX 11 system. It plays sounds using NAS. I had to patch libtool in order to build the shared libraries. If anyone wants it, I can let them have a list of all the modifications necessary to compile it with gcc-3.1." However, Ravikiran ran into problems with kdelibs as he reported saying, " Currently, I am trying to get kdelibs to work. Almost all problems are solved, except for a template based construction used in kgenericfactory.h which compiles but does not link. For more on that problem, see: http://gcc.gnu.org/ml/gcc/2002-05/msg03037.html (http://gcc.gnu.org/ml/gcc/2002-05/msg03037.html) "

Michael Matz replied saying, " Well, kde 1.1.2 was working on HP-UX 10.20 ;)

But for KDE 2 onwards: no, it never worked. It compiled in the past (even with aCC!), but never worked completely (some things like konsole, and kicker run, but others like konqui had many problems). Besides many small fixable problems there is (or was) one obstacle: Static constructors aren't run for shl_load'ed (dlopen equivalent) modules on HP-UX due to the way they are implemented with g++, and due to the shitty way, those things are implemented on HP-UX. It can't be made working without major work in either collect2, g++ or HP-UX (pick one ;) ). The effect of that often are strange crashes somewhere in the program. Sometimes when loading a module, sometimes only much later. Although note, that this was with g++ 2.95.x and HP-UX 10.20. Maybe they changed it to be sane in 11.00 (I doubt that), or g++ has the ability to make it work meanwhile (I can't test). I.e. I wish you luck with this ;)"

Allan Sandfeld Jensen replied to Michael saying, " the gcc 2.xx series never worked with HP-UX 11. Only the recent g++ 3.1 has made it possible to work on HPUX again. (I actually worked on KDE 3.0 for aCC for a while, but the STL on the system was broken, so I went back to playing with Sun CC and Intel C++)"

So perhaps there is hope yet for KDE on HP/UX systems!

5. A Lib For Edu

29�May�2002�-�2�Jun�2002 (34 posts) Archive Link: "[kde-edu-devel] And so it begins (libkdeedu)"

Summary By Juergen Appel

Topics: Code Reuse, KDE-Edu

People: Scott Wheeler,�Ewald Arnold

Reuse of code has always been one main goal of any developer, recently KDE-Edu coders started writing a library to just do this very thing, Scott Wheeler announced:

Per public and private discussion with Annma today, I've committed the first part of libkdeedu. With all of the hype around the use of Ewald's kvtml, Anma has been the first besides Ewald and myself to take the initiative to begin using it. Rather than having her copy and paste my poor implementation it seemed to be a good time to start to Do Things The Right Way (tm).

First, I made a lib based on my bad implementation of kvtml, but then my conscience got the better of me and I started tinkering with QDom. What you'll find in libkdeedu is a QDom based, very basic, parser for kvtml. Right now it just parses "e" (entry), "o" (original) and "t" (tranlation) tags, but it's done in such a way that it should be easy to extend (unlike my previous implementation). I've also made changes to FlashKard to do it's input using this.

So now, if you include "kedudata.h", you'll have access to two classes and a typedef. They are as follows:

KEduDataItem -- a class to store vocabulary items
KEduDataItemList -- a "typedef QValueList <KEduDataItem>"
KEduData -- a class that will later be used for kvtml documents but at the
moment just has one static member "parse(const QString fileName)".

The use is basically what I laid out in my earlier email:

KEduDataItemList list = KEduData::parse("foo.kvtml");
QString original = list[0].originalText();
QString translated = list[0].translatedText();
Also you'll need something like:

#include "../../libkdeedu/kedudata.h"

and in your Makefile.am:

flashkard_LDADD = $(LIB_KFILE) ../../libkdeedu/libkdeedu.la

So now some disclaimers:

This is very basic. There isn't much there, but that will change. Right now this is to suit Annma's needs (and FlashKard while I'm at it). Many gaps need to be filled in.

This is all *very* subject to change. In fact I guarantee it. If you're lucky, I'll only break your app a few times. Things will be moved, renamed, rewritten and the API will change.

This also means that it's open for suggestions. For the name of the lib, I followed the libkdenetwork pattern, but that can change. I arbitrarily picked the prefix "KEdu" for all of the classes and decided on the name "KEduData" for the vocabulary data. Ewald had suggested some other things but mainly based on having several KDE-Edu libs, which of course begs the question, should there be several? Looking around at other KDE things it seems pretty common to pack a lot of logically connected material into one lib.

Also propper (in-header) documentation will follow, but I want to get a little better idea of what the API will be before I spend the time to document it.

I'm really not trying to comandere this thing, I was just feeling productive, so I started coding.

I may start looking into writing something to write kvtml, but that will probably happen after a brainstorming session at LinuxTag.

Cheers and good luck!

This started a rather long discussion about using the parser that comes with Qt-lib instead of writing a new one. Scott Wheeler answered that QDom is not really a complete parser but much more of a framework, besides he provides us with an example to explain the benefit of a library:

Let me give an example of how things currently work, as opposed to how they *should* work. If I create a data file in KVocTrain, then open it in FlashKard, make some changes, and then save it in FlashKard, when I open it back up in KVocTrain it will have discarded all of the KVocTrain specific data. That's because I only used the parts of kvtml that FlashKard needs. That's how anyone writing their own kvtml implementation would do things, but it is not particularly helpful in our environment.

At first the library served programs dealing with vocabulary, but that is far less than it is supposed to do. Mathematical programs will benefit from a standartizised library as well as programs such as KEduca. In the continued discussion it was decided to split the library with Ewald Arnold saying, "as discussed I have set up cvs environment with two directories for the "core" and "ui" stuff. No real code yet, just the framework with some files since the weather was just too fine :-)"

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 kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.