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.

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.

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:

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 page.

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.

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!

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.