KDE Traffic #32 For 15�Feb�2002

By Aaron J. Seigo

Table Of Contents


Welcome to KC KDE! After a brief but widely felt loss of the KDE CVS and email servers KDE 3.0beta2 was released. Beta2 shows noticeable improvements over the first beta and several new bugs and problems were quickly identified with its released. Many of these have already been fixed in current CVS.

Much of the traffic on the email lists revolved around addressing the issues that became apparent in the second beta of KDE3, but there was also discussion of new development and the usual number of interesting discussions.

We hope you enjoy this week's summaries. Happy Hacking!

1. DCOP for C Programs?

26�Jan�2002�-�8�Feb�2002 (7 posts) Archive Link: "turning a C application into DCOP client ?"

Topics: DCOP, Development Language

People: Alexander Neundorf,�Tim Jansen,�Waldo Bastian,�Ian Reinhart Geiser

DCOP has been a rather successful part of the KDE desktop for the C++ applications that run on it. Regarding DCOP and programs not written in C++, Alexander Neundorf asked, " is it possible to turn a C application into a DCOP client ? I'd like to make mplayer controllable via DCOP, without rewriting it. Is this possible ? If would have to be done ?"

Tim Jansen replied succinctly, "In kdebindings is a dcopc package." Rolf Magnus added that these bindings rely on glib and gtk+. Waldo Bastian suggested a slightly different tack saying, " It's possible but will be a bit of work. In kdelibs/dcop there is dcopc which is a dcop client written in C. The aim here was _making_ DCOP calls, not _receiving_ calls. But it shouldn't be too hard to have that as well... If you are going to give it a try let me know, I will assist you with any problems that you might encounter." Presenting yet a third solution Ian Reinhart Geiser said, " Yes this is possible, there are C bindings for dcop and I am in the process of writeing some better ones. There is only one catch at this point, you must still link to QT. If you are interested please let me know."

As KDE expands its horizons efforts such as these will be important to gaining wider support and offering developers more options.

2. Sometimes You Bleed On The Bleeding Edge

1�Feb�2002�-�7�Feb�2002 (53 posts) Archive Link: "$%^#%&^@%&@%"

Topics: KMail, Accidents

People: Waldo Bastian,�Christian Tiberna,�Cornelius Schumacher,�Marc Mutz

Life isn't always fun and games on the bleeding edge of software development, but at least it usually leads to productive thought and consideration. A good example of this occurred when Waldo Bastian was testing a patch on KMail and ended up losing many of his email filters. Waldo wrote in an email entitled "$%^#%&^@%&@%", " Ok, who's idea was it to remove filter rules when the folder doesn't exist? I just tested KMail with 4 folders instead of my usual 30 and appearantly that was reason to throw away my filter settings for the other 26. Thank you very much... "

After it was pointed out that the filters were probably still in the file and just being permanently ignored, a long discussion of the problem with many suggestions and counter-suggestions ensued. Some of the suggestions included simply ignoring broken filters without discarding them, creating folders on-the-fly if they didn't exist and asking the user what to do with a filter that pointed to a non-existent folder.

Christian Tiberna also suggested, "I think that, finally, it is time to seriously ponder the extraction of filters from the kmail rc file. They aren't well placed there. They should be in a share/apps/kmail/filter file and backups of this file should be modified at modification." Cornelius Schumacher agreed saying, " That's a good idea. Storing the filters in a separate file without numbering, but an active/inactive flag would make handling of the filters much easier. Then the configuration for each filter would be self-contained and could be copied to other filter files, could be individually deactived or reactivated. The same is valid for accounts and identities." There was further discussion regarding this approach.

Finally after much useful discussion Waldo said, " I was actually considering something like "ignore filter-rules that use non-existant folders" and/or a dialog when a non-existant folder is encountered that ask whether you want to "create the folder" or "ignore the the filter for now". I will make a patch along those lines once I have finished my patch for cross-platform compatibility." Marc Mutz, the original author of the current filter scheme, chimed in at this point with some additional weaknesses in filter handling that need addressing.

So even though one may get bitten once in a while when using bleeding edge software, it does provide for good opportunities to examine and solve problems before they become an issue for more people in a stable release. This sort of trial-by-fire and open development is one of the most effective ways to ensure quality in open source software.

3. XSLT KOffice Filter

3�Feb�2002�-�11�Feb�2002 (5 posts) Archive Link: "xslt filter (again)"

Topics: KOffice, Filters

People: Robert Jacolin

The quest for more and better filters in KOffice has been joined by several developers lately. One of the more recent additions has been the XSLT filter which was announced by its author Robert Jacolin:

i'm just commiting the filter in filters/xsltfilter. I updated the filter/Makefile.am but I didn't update configure to compil the filter.

This filter have a dialog box to specify teh xslt file to use. I would want to use :

Someone can add the filter in the filter status page on the web site ? th status file is in filters/xsltfilter/status.html

The XSLT filter is now listed in the KOffice filter listing and continues to be worked on. A current listing of filters and their development status can be seen on the KOffice filters (http://koffice.org/filters/status.phtml) page.

4. KDE3 Fixes for IRIX

7�Feb�2002�-�8�Feb�2002 (8 posts) Archive Link: "kdelibs-3.0beta2 on IRIX"

Topics: Operating Systems, IRIX

People: Jesse Barnes

If you were having problems compiling KDE3beta2 on IRIX, you may want to try the next release. Jesse Barnes emailed a flotilla of patches saying, " Here's a list of issues and some patches for things I ran into on IRIX. Hopefully they'll be fixed for the final release. kdelibs.patch has 'good' fixes, while kdelibs-compiler.patch has ugly, kludgy workarounds for a bug in the MIPSPro 7.3 compilers." The patches were sorted through and committed or improved by various KDE developers. Some of the patches were applicable to any non-gcc platform and should be of benefit to more than just IRIX users.

5. aRts Moves To Its Own CVS Module

9�Feb�2002�-�11�Feb�2002 (12 posts) Archive Link: "arts CVS module ready"

Topics: aRts, CVS

People: Stefan Westerfeld,�Dirk Mueller

The aRts multimedia infrastructure has primarily been used by and developed for KDE, but over time it has received support from outside KDE, including from GNOME developers. As one would expect from such collaborations, the result has been an improvement in performance and reliability. To accommodate and reflect the broadening scope and appeal of aRts, Stefan Westerfeld announced, " I completed moving arts to its own CVS module now. To build kdelibs, you will need to checkout the new "arts" CVS module and compile and install it to the same prefix you will install kdelibs in. Sorry for any inconvenience caused by this move."

Dirk Mueller asked, "why the glib stuff is in arts/, while the Qt/KDE stuff is in kdelibs ?" Stefan answered, " Those parts that I left in kdelibs link against KDE libraries, like libkdeui, which makes it impossible to build them before kdelibs. However, qtmcop, which only requires Qt is in the arts/ CVS module."

Congratulations to the aRts developers on their continued progress and successes!

6. Making KDE Thumbnails Comply To Standards

11�Feb�2002�-�12�Feb�2002 (8 posts) Archive Link: "Thumbnail Standard, XCF reader"

Topics: KDE 3, Thumbnailing

People: Malte Starostik,�David Faure

Malte Starostik posted a patch for the file thumbnail generator saying, "I've ported KIO::PreviewJob to comply with the Thumbnail Managing Standard (http://triq.net/~pearl/thumb-spec.php). It doesn't change any i18n strings nor the outer appearance of previews except that the sizes are adjusted to be nicely scalable from 128x128, which is but a few pixels difference. As it adds to the interoperability with "foreign" applications, I'd really like to commit this for 3.0, but not without an okay. Either case, it requires a small Qt patch that reads PNG text chunks also for non-progressive loading (sent to qt-bugs@, answer pending)."

David Faure replied saying, " This sounds great to me. Interoperability is a move in the right direction ;) If this doesn't bring in too many bugs, I think it's a "must have"." David asked how critical the Qt patch was to have and Malte answered that it was required. Malte was later informed that the patch would be in Qt 3.1 and not 3.0.2, which may cause this particular improvement to be put off until KDE 3.1.

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.