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

KDE Traffic #37 For 21�May�2002

Editor: Juergen Appel

By Aaron J. Seigo ,� Chris Howells ,� Juergen Appel �and� Rob Kaper

Table Of Contents


Welcome to KC KDE! After Aaron J. Seigo has retired as editor, the Kernel Cousin KDE Team returns with some new members and two editors in a weekly change: Zack Rusin and myself, Juergen Appel. With KDE 3.0.1 to be released real soon, development focuses again on the upcoming 3.1 release including a Kopete that is taking more and more shape, an enhanced Kicker and besides an upgraded KBugBuster.

We hope you enjoy this week's summaries!

1. More Mathematics in KDE 3.2?

30�Apr�2002 (24 posts) Archive Link: "[kde-edu-devel] First Announcement Of KMathCenter"

Summary By Juergen Appel

Topics: Mathematics, KDE-Edu, New Application

People: Christian Parpart,�Anne-Marie Mahfouf

Christian Parpart recently announced a new mathematical application:

KMathCenter is a math science application wich intents to go into the kde-edu package set.

The current features of KMathCenter are:

  1. symbolic derivations
  2. symbolic expression simplifications
  3. string based expression calculation.
  4. analytic function plotter

The current features goals are as follows:

  1. symbolic expression integration
  2. symbolic expression expanding
  3. everything else you need to compute a complete curve discussion (I unfortunately can't say these things in english)
  4. scripting system for advanced mathematical algorithms
KMathCenter has also some requirements:
  1. KDE 3 (of course :o)
  2. OpenGL (at least MesaGL, software driven -
  3. (you'll also need its developer include headers gl.h and glu.h)
  4. libmath++ (is bundled into the package)
  5. ISO/ANSI C++ compliant compiler (that's mostly gcc3, for gcc2 exists a source level fallback, so it'll work there too)


Screenshots of KMathCenter made while coding on it are available at:

Download of that initial package for testing is available at:

You surely have noticed that KMathCenter is using libmath++, it's developement state till now may be reviewn at:


BTW: Qt's qgl.h also includes GL/glu.h even if it isn't ever needed. KMathCenter will never need that header but you need it because Qt thinks that it's needed. (That's not good!, since we noticed that average Mandrake users doesn't have either OpenGL nor its include files, such as the important glu.h for Qt! It's not my fault ;)

Anne-Marie Mahfouf replied concerning Christian's wish to include KMathCenter in the upcoming KDE 3.1 release, saying, "It seems difficult to include KMathCenter in HEAD for 3.1 due to the OpenGl problem and due to the fact that we already have KmPlot."

Discussion continued about merging KMathCenter with KMathTool, kmplot and other projects, but it was concluded that these applications can exist side-by-side.

2. Auto-away in Kopete

4�May�2002 (8 posts) Archive Link: "[Kopete-devel] Autoaway plugin"

Summary By Rob Kaper

Topics: Kopete

People: Ladislav Strojil,�Daniel Stone

Ladislav Strojil wrote in a suggestion for the AutoAway plugin of multi-protocol instant message client Kopete, saying, "The problem (at least for me) is that it restores status to available, no matter what it was before setting "away" status."

Daniel Stone confirmed this was due to differences between the protocols, saying, "This is indeed the only way to handle this. Since each plugin stores its own status - int, QString, whatever, and in an incompatible way, and sets its presences differently, this would have to be implemented on a per-plugin basis"

The discussion soon focused on using the KopeteStatus class by Ryan Cumming, encapsulating the away modes from different protocol plugins. While it was agreed upon that this would be the ideal solution, there was no response to the list that such a class was already existing. Lada finished the thread, indicating a will to write the necessary code, saying, "OK, I am willing to do that, I'll ask Ryan about it and if there is nothing I will start from scratch. I may need your assistence however, I am new to kopete development (well, to be precise I started looking at the code yesterday)."

3. Kopete design discussions

8�May�2002�-�13�May�2002 (14 posts) Archive Link: "[Kopete-devel] more design discussions (an also,KMMF bugs)"

Summary By Rob Kaper

Topics: Kopete

People: Andres Krapf,�Martijn Klingens

Kopete is one of the newer KDE applications and as such the developers are still frequently discussing design issues, trying to create a unified and consistent interface while handling various protocols and their differences. A special CVS branch exists for the new KMM message window.

Andres Krapf wrote a lengthy e-mail about some problems with the current KMM design and suggested:

the best way i see to keep using the nice KMM functionality while allowing full customisation is either to allow subclassing of KMMs (which i think is a good thing).

if we go that way, there's the probem of the factory. we could use a factory method provided by the plugin, but then we'd have to dynamic cast like here:

(inside, say, AIMProtocol class)

/* this calls the KMMF::create which in turns calls some method provided by the plugin which creates a AIM specific AIMProtocol*) */ KMM* kmm = sessionFactory()->create(blah); /* we have to dynamic cast */ AIMProtocol* aimkmm = dynamic_cast<AIMProtocol*> kmm;

a better solution might be to use a factory template. like this:

template <class KMMT> class KMMFactory { KMMT create (blah) { if exists blah inside KMM list return KMM list item; else return new KMMT(blah); } }

so that we reuse the code, but each protocol gets its own factory returning its own KMM (AIMKMM, ICQKMM .....) and we don't have to dynamic_cast.

we could still provide the generic KMM for plugins which don't require any customization (or aren't there yet).

comments ?

Martijn Klingens responded:

Yes: what the heck do you need this for? It is extremely complex, messy and sounds seriously overengineered to me. Is there a *need* for this or are you thinking about things like 'well, we _might_ want to do blah in the very distant future and then we need this' ? If so I'd rather leave things as they are now, fixing what needs fixing *now*. I want all plugins to use KMM ASAP and stabilize to get Kopete 0.4 out of the door based on it. After that we're a long way to shared code and then it might be a nice time to talk about the API again. We're not heading for BC yet, so please take small incremental steps. After all, open source is 'release early, release often', and this way the gap between Kopete releases will be *way* too big. If you need this to stabilize or finalize the current code then please explain and we might incorporate it. In all other cases: please wait at least until KMM is back into HEAD and a Kopete 0.4 is out. After that, start the discussion again.

While the pros and cons of the different approaches were discussed even further in the following e-mails, it was agreed upon that such a redesign and discussion about it should indeed be postponed. It should be interesting to see how Kopete struggles with growing into a mature application. There still seems a lot to be done, but the volume of traffic on the mailinglist and dedication from its developers promise a lot for the future.

4. Kicker usability improvements added to CVS

11�May�2002 (1 post) Archive Link: "kcm / kicker changes committed"

Summary By Chris Howells

Topics: Kicker, KDE Usability Project

People: Aaron J. Seigo

For some time, the KDE Usability Project has been discussing various usability issues in KDE and working on improvements in many of the small-but-useful programs such as KSnapshot. More confident and experienced, the team decided it was time to concentrate on other areas of KDE. The Kicker configuration dialog and KControl module was chosen as the next candidate. After a lengthy period of discussion with input from a wide range of people on the kde-usability mailing list, and coding the required changes, Aaron J. Seigo posted a message to the mailing list to represent the culmination of this phase of the KDE Usability project:

i've committed the changes to the kicker kcm and kicker itself. documentation, proofing the spelling and contents of the tooltips and WhatsThis help, and getting rid of the extensions panel in the kcm is left to do (along with processing any bug reports / complaints / questions that this commit incurs)

thank-you to everyone who provided criticisms, feedback, improvements, opinions, etc etc .... without your ideas and input it wouldn't be *nearly* as good as it turned out.

this is probably the most visible change yet to come out of the usability project and i think that it has gone very well so far...

There were no further replies in this thread.

5. Managing Bug Reports

14�May�2002�-�16�May�2002 (7 posts) Archive Link: "Fwd: Handling of Bugs"

Summary By Aaron J. Seigo

Topics: Bug Tracking, New Application

People: J�rg Mayer,�Marc Mutz,�David Faure

The KDE Bug Tracking system is an excellent resource for both users and developers. It serves as a mediation point for defect reports and wishlist items that can be driven by the web interface, email or the KBugBuster application. The system does require that people use it to be effective, however. David Faure forwarded on an email from J�rg Mayer who said:

Having reported/opened a few bugs and having looked at some bug reports before opening I've come upon two things that I'd like to comment on (aka criticize :-)

  1. When you close a bug, please indicate which release version is likely to contain the fix (I just wanted to report a bug and found that it was fixed and closed on March 8th, but I'm still seeing the bug in kde 3.0, so does opening a bug report make sense?)
  2. When you close a bug as a duplicate, please indicate of which bug this is a duplicate. I've had one of my bugs closed as a duplicate but even after searching for that bug, I haven't found it. I've also seen a few more bugs that were closed as duplicates without me being able to find the original one.

Marc Mutz agreed with the first point but took exception to the J�rg's second assertion saying, "IMO it's the reporter's job to find the dup or simply believe us. I had someone mailing me that he "searched" the wishlist items of KMail and didn't find a dup of item I had closed as being duplicate. _Two_ days later, he wrote back that he had indeed found one. I _know_ duplicates when I see them, the more so as I have been going to all the wishlist items recently, cleaning up. Yet I cannot afford to search the exact number everytime I close a wish/bug. It'd regularly take 10+ minutes to find that I can't find it myself. But it _is_ there."

It was pointed out that KBugBuster has an offline mode for those who don't have flat-rate Internet access. Some suggested that KBugBuster would be more useful with a full-text searching mechanism. KBugBuster is a very good tool and a step in the right direction, but evidently more needs to be done before it is the bug report handler's dream system.

6. Keramik KWin decoration added to CVS

17�May�2002 (1 post) Archive Link: "kdebase/kwin/clients/keramik"

Summary By Chris Howells

Topics: Look and Feel, Art, CVS

Fredrik Hoeglund recently added the Keramik KWin decoration to CVS, to complement the highly original Keramik widget style which has been in the development version for a while, although unfortunately not included in KDE 3.0.

Both the KWin decoration and widget style look superb. Well done!

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.