KDE Traffic #36 For 15�Mar�2002

Editor: Aaron J. Seigo

By Aaron J. Seigo �and� Timothy R. Butler

Table Of Contents

Introduction

Welcome to KC KDE! RC3 was released this week, marking an important milestone in KDE development. The overall stability and continuity of this release was noticeably better than the previous pre-releases. In fact, current KDE CVS has shaped up to the point that your editor is now using it as his daily work desktop, relegating KDE2 to sit dormant in /opt/kde2/.

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

1. Advanced Media Streaming

1�Mar�2002�-�9�Mar�2002 (18 posts) Archive Link: "[PATCH - update] advanced multimedia streaming for KDE"

Summary By Aaron J. Seigo

Topics: Multimedia, aRts

People: Matthias Welwarski

Matthias Welwarski has been busy implementing streaming media support in KDE and aRts. This week he posted a set of patches along with a description of his progress, saying:

I've been working to stabilize the patch a bit, results are promising. So, once again for the announcement: This patch adds the following features/extensions to KDE:

This patchset also contains fixes for kio_audiocd and kaboodle that are valid without the streaming extensions and should go into CVS before KDE 3.0

The set of patches Matthias posted touched aRts, libkdearts, kaboodle, mpeglib (and its corresponding aRts plugin) and the audiocd KIOSlave. Shortly thereafter Matthias posted a new set of patches that merged in changes from CVS. This new set included patches for Noatun. Matthias noted, " Efficiency is an issue, though. Data is copied multiple times on its' way from the IO-Job into the Playobject and into mpeglib - for now I don't care, it doesn't matter for low bitrate stuff, but for video streaming there are quite some improvements to be made." When asked what media types were streamable with his patches Matthias said, " any mpeglib decoder that has a playobject in mpeglib_artsplug and is derived from DecoderBaseObject should be streamable."

2. KParts and Streaming Data

3�Mar�2002�-�7�Mar�2002 (21 posts) Archive Link: "KParts API: thinking about the future (patch)"

Summary By Aaron J. Seigo

Topics: KParts, KDE Core Development

People: David Faure,�Waldo Bastian,�Martijn Klingens,�Dave Faure

KParts has proven to be a very successful technology, but KDE is not a project that tends to sit on its laurels. KDE developers have been examining various ways to improve KParts and make them even more powerful. Regarding one aspect in which KParts can and should be improved, David Faure said:

The current API of KParts::ReadOnlyPart is centered around "open a URL, emit signals while doing it, and display it". What would be needed in some cases, though, would be to be able to send data to a part, from the "outside", without a URL available. One could call that "streaming": having a way to load data in any way, not restricted to ioslaves, and send it progressively to the part so that it can display it.

One example is the kmultipart stuff I put in kdenonbeta ("server push" support), it currently only supports HTML because only khtml has begin/write/end for sending data to it.

Other examples could be.. using a text editor component to pipe a log file to it (never-ending stream, unlike a direct openURL of that file), and maybe more advanced stuff later (movies?).

A technical discussion ensued regarding implementation details. At one point Waldo Bastian suggested, " another approach could be to use internal IO-slaves. E.g. you would pass a URL that points to an internal IO-slave and the part would then ask for that URL and get's it data from this io-slave. I must say your solution is more elegant but the drawbacks would be that the KPart(s) need to be adapted to it. You will never be able to rely on all parts having support for this stream extension."

Martijn Klingens responded, " Well, both in your multipart case and in my case it is absolutely required that the part supports streaming. So we have to make completely sure from the hosting application that we only load parts that support streaming / progressive loading. Using the existing KParts interface with internal KIO slaves does not automatically guarantuee that this is the case for each and every KPart that can is and will be written. Since internal slaves have their own advantages I'm not really opposed to them, but then we definitely need a method in the KParts API to signal whether the part supports progressive loading" David also added, " Compared to the internal IO slave, I like the idea of the virtual methods because they're much more straightforward. Less "hidden magic" involved."

3. Highlights of Highlighting

4�Mar�2002�-�11�Mar�2002 (7 posts) Archive Link: "perl highlight"

Summary By Timothy R. Butler

Topics: Kate

People: Anders Luhn,�Christoph Cullmann,�Christoph Cullman

Since its initial appearance in KDE 2.2, Kate has offered very nice syntax highlighting for a large number of different formats. However Anders Luhn (mailto:anders@alweb.dk) was unsatisfied with the existing Perl syntax highlighting and decided to improve it:

I have finally taken the time to update the perl hl to the new times

This has highly improved the hl, ao typing has improved a lot, though there are still room for improvements. Please test and comment if you'd like

Anders then followed up on his initial posting with additional improvements, which he committed to CVS. Finally, he wrote in again with a few general highlighting patches:

The attached patch has the following effects:

  1. the hl detection in saveFile has been fixed to actually work with content based detection. This code is repeated in opendocument - wouldn't it be better to implement it as a function btw?
  2. the hl is only saved to document session config if set by the user, that way that property can be set when reading session config, and thus the correct hl will be used after saving a file reopened from the kate session.
  3. mod time is saved to document session config, and bookmarks only restored if the document is not modified after it was saved.

Christoph Cullmann (mailto:cullmann@babylon2k.de) responded to Anders' patch, saying "Seems to be a good idea ;), please commit it, if not allready done" . The conversation wrapped up with Anders committing his third highlighting patch of the week.

4. Moving Day For Wallpapers

7�Mar�2002�-�8�Mar�2002 (26 posts) Archive Link: "kdebase wallpaper bloated"

Summary By Aaron J. Seigo

Topics: Art

People: Duncan Mac-Vicar Prett,�Stephan Kulow

Regarding the size and number of wallpapers included in kdebase, Duncan Mac-Vicar Prett asked, " Isn't 31 wallpapers for kdebase too much? 2 should be enough and the rest fit better in kdeartwork. What do you think?" Stephan Kulow said, "We want choice. Most of them are really small." This viewpoint was countered by several others, who pointed out that many didn't want the extra wallpapers and that the kdeartwork module was created for these sorts of add-ons.

Agreement on the matter was reached and most of the wallpapers were moved to kdeartwork. Three choice wallpapers and ten tiles were kept in kdebase.

5. KOffice: A Little Bit of Publicity Never Hurts

7�Mar�2002�-�8�Mar�2002 (14 posts) Archive Link: "consequences of the interview"

Summary By Aaron J. Seigo

Topics: KOffice, Promotion

People: Philippe Fremy,�David Faure

Following up on his very interesting and widely read interview with KOffice developers (http://www.freehackers.org/fosdem2002/koffice.html) , Philippe Fremy explained his motivations for writing the article: " One of my goal with the KOffice interview was to attract attention on KOffice, and to attract developers. Do you think it has had some effects ?" David Faure replied, " Oh yes ;) You should see the number of patches that arrived onto koffice@ and koffice-devel@ for the last week. Many people joined, and I was impressed at the quality of the patches I saw. I think everyone who sent a patch and announced willingness to continue working on koffice, has a CVS account now, and suddenly there _is_ work going on, on most koffice applications and filters. This is great, thanks to all those who joined, and thanks to you two for conducting this interview!"

6. RC2 Released

9�Mar�2002 (5 posts) Archive Link: "KDE 3.0 RC2 ready"

Summary By Aaron J. Seigo

Topics: KDE 3

People: Dirk Mueller

Dirk Mueller announced the availability of RC2 saying:

I've put up new tarballs on

download.kde.org/pub/kde/unstable/kde-3.0-rc2/

Please test them. There is one week left to decide if these tarballs are good enough to be released. If not, I will redo the tarballs again next week and there will be another week for testing and fixing.

You can check out which modifications made it into the tarballs by looking at the KDE_3_0_RELEASE tag in CVS. The admin-dir-with-autoconf 2.13 patch is not in them, it takes too long to redo the packages for me and it shouldn't matter for the tarballs anyway.

Please remember that the CVS is frozen for non-critical bugfixes and feature commits. The translators need time to polish the translations so do not introduce any new i18n string. Please post your patch for review first.

Problems with the aRts tarball were quickly found and addressed. It was also confirmed that while this release contained the new admin dir, no autoconf or automake upgrades would be necessary since the tarballs were already processed as part of the packaging exercise.

RC3 has since been released.

7. Tracking What's Left To Do For KDE 3.0

9�Mar�2002�-�10�Mar�2002 (7 posts) Archive Link: "KDE 3.0 Planned Features"

Summary By Aaron J. Seigo

Topics: KDE 3

People: Rob Kaper,�Daniel Naber,�Neil Stevens,�Dirk Mueller,�Waldo Bastian

Helping to keep everyone appraised of what is left to be accomplished for KDE 3.0, Rob Kaper said:

Half of our planned features are still listed as "In progress / works mostly" instead of "Finished" on the 3.0 Planned Features list on http://developer.kde.org/development-versions/kde-3.0-features.html (http://developer.kde.org/development-versions/kde-3.0-features.html)

Can the responsible developers please take a look at this page again and work on these areas with uttermost priority? We cannot possibly aim for a release when half of the planned features apparently are not labeled as finished.

We might also benefit from a "planned bugfixes" page, listing showstopper bugs. Right now many developers do not know what the exact status is of the 3.0 release and what goals there are for bugfixing in what areas.

Daniel Naber replied, "I like that idea and I suggest that it only needs to consist of links to actual bug reports (bug number plus title as a short description). We could also use the "critical" severity, all those bugs are listed here (currently none): http://bugs.kde.org/db/si/pendingcritical.html So the system exists, we just need to use it."

Neil Stevens agreed with Daniel and added, " Since kbugbuster came around, I've noticed a lot more bug reports being transferred to my code. I take this as a sign that kbugbuster should make it a lot easier to start using the bug system in this manner. So this would work just like the planned features. A package maintainer moves to critical those bugs he plans to fix, and periodically the RC reminds everyone to hurry and fix them, and eveyrone uses the list of criticals, combined with the planned features, to gauge how close the release cycle is to meeting the intended goals. "

Both Waldo Bastian and Dirk Mueller piped in saying that a "Show Stoppers" section on the Planned Features page would be excellent, and Rob quickly added it.

8. Admin Updated, Requires Auto* Upgrades

10�Mar�2002 (9 posts) Archive Link: "That admin/libtool update"

Summary By Aaron J. Seigo

Topics: KDE Core Development, Building KDE

People: Michael Matz

The admin/ directory that is found in each KDE module facilitates the build process. When this important bit of infrastructure was quietly updated, many KDE developers discovered that they had to upgrade to newer automake and autoconf packages. There was outcry that the change was made without announcement or explanation. To address this faux pas, Michael Matz prepared the following belated announcement:

short version:

long version:

the last days there was some heat on the lists about the recent libtool update. My mail to kde-core and kde-solaris/nonunix obviously wasn't enough, and I can understand people seeing it like this. I should have mentioned, that it requires autoconf 2.5x. That it will need relinking everything is something which I considered immediately clear, but obviously I was wrong in that respect. [...]

Anyway we (I) had good reasons to not only update libtool, but also put it into the release candidate. Please do not think we made this decision lightly. The libtool we were using was based on a discontinued version of libtool, which never has seen a release. Not only that, it also was heavily changed for KDE. This became more and more of a burden. One reason is, that we couldn't incorporate easily changes from the libtool maintainers (because they are working on a completely different code base), another reason is that we were getting bugreports, which couldn't be easily forwarded to the libtool guys. The reason for really really wanting it in the release candidate should be obvious: more testing. As it also changes some bits in the built libraries we don't want such an update in some minor version, so KDE 4 would be the next opportunity. Until then it probably would've broke apart. So the time was pressing. Eventual build bugs can be fixed the next week, even without needing a new release candidate (that's currently only my opinion, but I think Dirk will agree).

Now to the technical side. The current system is known to work with autoconf 2.52 and automake 1.5 on linux. For automake 1.4 I installed a hack, so that seems to work too. automake 2.53 gives strange warnings which are not caused by us, at least that's my current belief. automake 1.6 isn't tested by me (was just released some days ago), but reported to have issues. Those things I will investigate. Some months ago I considered to "port" the then current libtool back to autoconf 2.13, but never really did the work, partly because it's not really usefull, as 2.5x is widely available, but see below.

For rebuilding: either start completely from scratch, or remove (in the builddir) all .la files and all executables. Remove config.cache, Make Makefile.cvs, reconfigure, rebuild. Done. There was a small time window where kdesupport was broken, just at the time libtool was updated. If you get strange warnings about libxml.la or libxslt.la, update kdesupport and rebuild.

autoconf/automake are development tools. They are not needed for those downloading tarballs/snapshots or release candidates. I.e. they are needed only for developers. I expected developers to be able to update two stinky packages on their own. There are other projects which have much stricter prerequisits, than just some version of autoconf/make released a long time ago. Sorry, but I can't resist to say: If you fear about "updating you operating system" (although I find it strange that someone believes to have to update a system for a package), then for gods sake, just install that tool into /usr/local, which is even how it installs itself by default. Or to be really really sure, into $HOME/install. That way it can't disrupt anything.

That being said yesterday coolo installed a hack for all who didn't want to update auto*. Please be aware, that this will not last for long, and bugreports against admin/old-* will be forwarded to /dev/null. Please use more current auto*, and try to find build bugs with them, which exist, I'm sure. Even more so, on archs != linux, as the new libtool is a little bit stricter.

9. Graphics In KOffice Documents

10�Mar�2002�-�11�Mar�2002 (4 posts) Archive Link: "New KoPicture code"

Summary By Aaron J. Seigo

Topics: KOffice

People: Nicolas Goutte

Over the last few weeks there has been discussion on the KOffice development list regarding how to effectively and generically handle graphics and clip-art in KOffice. Since graphics come in a variety of disimilar formats and can be inserted into most KOffice documents, the challenge was not a simple one. Nicolas Goutte wrote to announce his initial efforts in implementing the required functionality saying:

I have finished the first code for KoPicture. I have the code for lib/kofficecore and for KWord. KPresenter is not touched and can still work with KoImage/KoClipart. [...]

New features of the code:

What has not changed:

Know bugs:

With its introduction into CVS several bugs were uncovered, identified and patched. Nicolas later updated the list with his progress saying:

For me, this version loads, displays, saves and re-loads (at least in KWord.) I am sorry for the inconveniences of the previous version. Thank to Toshitaka Fujioka for pointing me the errors (load/save) and for the code that he has written.

The main change is a new class KoPictureShared, which is now the (only) class being QShared. Therefore data can be shared more easily and the problems of the first version can be corrected with simplier code.

Other changes:

I will remove any of the koImage*.* and koPicture*.* files (in lib/kofficecore.) Therefore if anybody still uses the classes defined there in any program (perhaps in a non-CVS one), he should tell it quickly.

10. Transitioning to the New Addressbook

11�Mar�2002 (10 posts) Archive Link: "is kab working (kdeutils ), i get a crash"

Summary By Aaron J. Seigo

Topics: KDE 3, KAddressbook

People: Cornelius Schumacher

A user testing one of the KDE3 RCs asked why KAB kept crashing. Cornelius Schumacher replied, " kab isn't compiled by default. It is not yet ported to the new addressbook API (kdelibs/kabc). You probably called the old 2.x kab. I don't know why this crashes. You can use KAddressbook as replacement for kab."

This raised concerns over how easy it would be to import contact information that had been stored in the now-deprecated formats. Cornelius again replied, saying:

If you don't change your $KDEHOME (usually ~/.kde), all old data gets imported automatically when you log into KDE 3 for the first time. This also includes the data from the "traditional" addressbook of KMail.

If you use a new $KDEHOME for KDE 3 (e.g. ~/.kde3), you have to copy $(OLDKDEHOME)/share/apps/kab/addressbook.kab to the same location in your new $KDEHOME. If you used the traditional addressbook of KMail you have to copy the file $(OLDKDEHOME)/share/apps/kmail/addressbook to the new $KDEHOME.

You can import the old addressbooks either by calling kab2kabc from the command line or by using "File->Import KDE 2 Address Book" from KAddressbook. The import can be done multiple times, it will not create duplicate entries or overwrite any data.

If you encounter problems with the import of the old addressbook please let me know and I will try to fix them.

11. The Path Forward: RC3 and Then ... ?

11�Mar�2002�-�12�Mar�2002 (10 posts) Archive Link: "[RC] Updated release plan"

Summary By Aaron J. Seigo

Topics: Release Schedule, KDE 3

People: Dirk Mueller

Dirk Mueller updated the release schedule and wrote:

Monday March 18th, 2002: Preparing RC 3

3.0 RC3 tarballs are made and uploaded, which incorporate the CVS changes since RC2 tarballs. Remaining showstoppers are identified.

Thursday March 21th, 2002: Decision about 3.0 final

Manually selected changes since the RC3 tarballs are integrated into the proposed final tarballs. A check of the showstopper list will decide if these tarballs are final. In this case, they're made available to the packagers and roughly a week later announced to the public. If not, the schedule is delayed by another week.

Requesting comments and suggestions, a discussion ensued regarding the relative quality of the previously released betas and RCs.

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.