KDE Traffic #9 For 15�May�2001

By Aaron J. Seigo

Table Of Contents

Introduction

Welcome to KC KDE! After a schedule-related challenge that prevented last week's issue from appearing, we are back again with a summary of the last week's development mailing lists. The week in KDE development was marked by incremental improvements all across the desktop. Kicker picked up several nice improvements including being able to hide child panels, nice text-fading effects in the taskbar and the ability to group all of an application's windows into one button. Konsole session support was started, the printing system improved and work on the khtml widget saw much refinement. KOffice also picked up a few new developers who have started posting on the mailing lists and contributing code. It's enjoyable and even exciting to watch KDE2.2 unfold before our eyes in CVS. Kudos to all the KDE hackers!

Another event of interest that occurred this week was a poll that appeared on KDE.com (www.kde.com) which asked what people thought should be the highest priority for KDE Developers as KDE2.2 approaches. Requests for greater speed topped charts which prompted quite a lot of discussion. Waldo Bastian posted a white paper entitled Making C++ Ready For The Desktop (http://www.suse.de/~bastian/Export/linking.txt) that documents features of the GNU linker and compiler that impacts C++ start up speed in a negative way. This in turn spawned discussions on both the libc-alpha list (http://sources.redhat.com/ml/libc-alpha/2001-05/msg00025.html) and the gcc list (http://gcc.gnu.org/ml/gcc/2001-05/msg00355.html) . (Thanks to Bill Soudan for providing the gcc lists links.)

The same poll also caused the KDE developers to consider various issues such as including system configuration tools as part of the KDE project and providing better user feedback in Konqueror while it is fetching and loading remote documents.

1. The Challenges of Open Development

30�Apr�2001�-�2�May�2001 (34 posts) Archive Link: "Possible cause of kivio problems"

Topics: KOffice, Accidents

People: Kurth Granroth,�Shawn Gordon,�Martin Konold,�Ben Burton,�Waldo Bastian,�Kurt Granroth,�Shawn Gorden

TheKompany has donated several pieces of work to the KDE project and they are now housed in KDE's CVS. Recently Kivio, the diagramming software for KOffice maintained by TheKompany, stopped working properly (connectors wouldn't connect any longer). No one at TheKompany knew what was causing this problem, only that the bug was not the result of a change made by someone from TheKompany. This prompted TheKompany to ask for access controls to be placed on the Kivio source tree. Kurt Granroth announced this move, saying:

On the request of theKompany, I have implemented ACLs for the Kivio module. It is closed by default to everybody unless specifically allowed. If you find your commits rejected and you think that you should be allowed, let me know.. and more importantly, let me know why! Please CC: Shawn Gorden when you do so, as well.

Almost immediately there was an uproar over controlling access to the CVS tree. Shawn Gordon of TheKompany explained the rational behind the move saying, "The reason at the moment is because unexplained things are suddenly happening to Kivio that are causing problems with it just after we announced its 1.0 stability, and it leaves us with egg on our face and a ton of support emails. Once we get everything cleaned back up and stable and KOffice 1.1 is out then we can see what is going to work best. Our hope is that people would respenct our position as the main application maintainers as they do for other applications." Martin Konold replied to this with his feelings on the matter saying, " I do not buy this. This is about the CVS version not about a stable 1.0 release. IMHO it is better to deal with the relevant problems which might be caused by some check in by talking/mailing to the relevant developer not via ACL."

Ben Burton eventually stepped in with something constructive regarding the possible cause of the Kivio problem. He wrote to the list and said, " I've written this to a mailing list and to a kivio developer but nobody has conformed or denied my suspicions. Basically I believe the reason the connector tool is no longer working is because libkiviopart.so is no longer directly linked to /usr/bin/kivio; instead it is being dlopened and as a result straight_connector.ksp can no longer find symbols it needs from libkiviopart.so." This suspicion was confirmed by other KDE programmers as probably being correct. Eventually the exact CVS check in that caused the problem and why it caused the problem was tracked down and rectified.

Debate continued to go back and forth regarding ACLs in CVS and how code written by a company should be treated if it is in KDE's general CVS repositories. In the end cool heads prevailed and Waldo Bastian announced: "Update: The ACLs for Kivio have been removed again."

2. Updated KOrganizer Developer Documentation

3�May�2001 (1 post) Archive Link: "KOrganizer developer documentation"

Topics: KDE PIM

People: Cornelius Schumacher

For those interested in hacking KOrganizer code, Cornelius Schumacher announced: "I have updated the architecture overview of KOrganizer on http://korganizer.kde.org and put the API documentation online at http://korganizer.kde.org/dox/korganizer. This was generated with Doxygen and gives a quite complete overview of the inner workings of KOrganizer. Have a look at the collaboration diagrams. Doxygen rocks."

3. Man Pages For KDE

4�May�2001 (4 posts) Archive Link: "Man pages (kdesdk, koffice)"

Topics: Documentation

People: Bent Burton,�Ivan E. Moore II,�Lauri Watts,�Ben Burton,�Ivan E. Moore

Documentation is always a good thing and therefore its nice to have people like Ben Burton around who announced, " I have a set of man pages written for all the apps in kdesdk and koffice. In particular this includes every command-line utility in kdesdk (of which there are many). You can find them all in the CVS under kdesdk/debian/*.1 (and koffice/debian/*.1). Aspects of the man pages that are debian-specific: Some of them refer the reader to author's notes, html docs and the like in debian-specific paths (eg. /usr/share/doc/kword/html). The man pages for qtdoc and kdedoc (from kdesdk) are very debian-specific since I patched the scripts to look for the corresponding Qt/KDE docs in the debian-installed locations; both of these man pages also have a DEBIAN USERS section detailing how to get the Qt/KDE docs."

Ivan E. Moore II replied saying, " speaking for the rest of the man pages...those currently in kdebase include 2 for kdm (kdm.1 and kdm.options.5) and one for konqueror. I created the konqueror one myself so as to create an example for building of other man pages..the kdm manpages are the xdm man pages in disguise. (ie, cp xdm.1 kdm.1 and then sed -e 's#xdm#kdm#' )..." Lauri Watts of the KDE documentation team acknowledged these welcome additions. Lauri also noted that when it came to keeping the man pages in *roff format, "man index.docbook doesn't work so well! This is the mechanism we're figuring out now, but it's a given that docbook is a source format, not an end result."

4. System Configuration Tools?

4�May�2001�-�6�May�2001 (42 posts) Archive Link: "System Configure tool"

People: Charles Samuels,�Matthias Elter,�Andreas Pour

In response to the kde.com poll where requests for system configuration tools did fairly well in the early days of the voting, Charles Samuels said:

Upon reading the latest article at The Dot, I've come to the conclusion that we need to write a Generic System Configuration tool.

And I'm now volunteering to kickstart it, despite the fact that I promised to not :)

But before I begin, I want volunteers to help out. At least 2 more people other than myself :)

Isn't this the responsibility of the vendors? Yes, and no. Yes, because they're the jerkwads that can't decide on the standard for configuring these things, but no, because they're a) incompetent and can never do it right and b) we want the best for our users and ourselves. Or at least I think we do on point b... ;)

How do I indend to acheive this? We'll be abstracting both the configure system, and the user-interface. and both of these components will be dlopened. This is to make it possible to have a console version, and a KDE version, with the same configuration backend. You want a console version for only a few specific modules, particularly stuff to configure the X server ;)

Matthias Elter didn't agree that this was a good idea, refuting several of Charles' points in his email and concluding by saying, " Sounds like a linuxconf rewrite. Better forget this, SuSE, Caldera and Mandrake, Redhat are all working on configuration tools. SuSE and Caldera implement them as kcontrol modules. Both do a pretty good job at it, just wait for the new versions." In turn, Adreas Pour wrote a lengthy email defending the concept of a configuration tool project, saying, " IMHO there is a lot of substance to what Charles said, not b/c distributors are incompetent but b/c they have their self-interests to consider. Whereas UNIX of old was severely hampered by API differences, the same will happen to Linux of new with GUI differences, unless this problem is nipped in the bud... for some configuration things it is *imperative* to have standards, and the distributor approach will not lead to standards. If you look at all the standards in Linux, I can't think of one that came from the distributors. They are always trying to set themselves apart by doing effectively "proprietary" stuff." To drive his point home, Andreas said, "You want to support splintering at the long-term expense of KDE and Linux, let the distros handle all this stuff; you want a standard way of doing things that will make Linux/KDE much more user-friendly and promote the long-term success of KDE, use a standard configuration utility for these things."

The debate over wether or not this was a good idea or not went back and forth for a few days. Eventually Charles said: " We now have a mailing list, subscription info is here: http://www.derkarl.org/kdesysconfig.phtml" No amount of rhetoric can stop someone from coding what they want in the open source world.

5. Further Printing Achievements: Fax and PDF printing

6�May�2001 (4 posts) Archive Link: "Fax/PDF/... integration in KDE print"

Topics: Printing

People: Michael Goffioul

Michael Goffioul, printing system coder extraordinaire, announced on the core-devel list: "I commited today a new feature in KDE print code: the ability to sent the print file to a 3rd party program instead of regular printer. You have then a set of pseudo-printers along with the regular ones. Printing to a pseudo- printer will start an external program as subprocess. Configuration takes place in an external XML file which describes these printers with some options (command line, icon, description, ...). Graphical configuration is planned but not implemented yet. I created by default 3 pseudo-printers:

"

Some discussion followed regarding the capabilities and availability of various fax servers and back ends for Unix and Linux.

6. New Mailing List for KDE Events

7�May�2001 (7 posts) Archive Link: "KDE Events Mailinglist"

Topics: New EMail List

People: Ralf Nolden

As KDE grows, more attention is paid to the details of interfacing with the public and coordinating events. To this end, we have seen several new initiatives within the KDE project such as the KDE promotional discussion group. In a continuing effort to properly address these needs, Ralf Nolden announced the latest development on the PR front saying, " coolo has set up a mailinglist for organizing KDE events. Please subscribe there to discuss these issues; all infos and lists who will be there and what the general rules are will be posted: http://master.kde.org/mailman/listinfo/kde-events"

7. Quality Assurance Testing Team Needed

9�May�2001�-�10�May�2001 (7 posts) Archive Link: "CALL for QA team (was about kde.com poll)"

Topics: Bug Tracking

People: Stephan Kulow

Are you a KDE'er who would like to help out the project but aren't a coder, artist or documentation writer? If so, Stephan Kulow announced a need in the KDE project that you might be able to help with, saying, " We urgently need at least three of four people cleaning up that mess for us. I for one don't have the time to do the cleanup necessary. I try my best, but I can't do it. People still report bugs to "/kde/index.html", "kdelibs", "general", "unknown" that are all meant for some other package. Bugs have to be tried to reproduced with current CVS (khtml/konqueror come to mind). Bugs have to be classified. I know quite some examples where I read by Ferdinand that bug xxxx should be fixed and I could fix it within an hour, even when not maintaining the code, but I wouldn't find such bugs on bugs.kde.org. And I'm surely not the only developer having that problem."

Discussion ensued regarding how the various programmers were currently handling bug reports. However, a trip to the bugs.kde.org system shows pretty quickly that they could use some help sorting and sifting.

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.