KDE Traffic #12 For 1�Jun�2001

Editor: Aaron J. Seigo

By ,� Aaron J. Seigo �and� Rob Kaper

Table Of Contents

Introduction

Welcome to KC KDE! With the KDE CVS unfrozen again development is going at its usual break neck speed. This week's online discussions highlighted several of the better aspects of Free or Open Source software development, namely cooperation, collaboration, attentiveness to the user's needs and the community these traits breed. The conversations covered in this KC KDE issue also reflect this.

For example:

There have been opinions flying around the Net that the Linux desktop is dead. These naysayers are simply not looking at the energy in and around the desktop projects. Following the CVS activity and online interactions surrounding KDE for even a single week would tell them otherwise.

Enjoy and Happy Hacking!

1. Abiword, wvWare and KWord Authors to Collaborate

23�May�2001�-�24�May�2001 (5 posts) Archive Link: "invited by abiword to work together on doc import"

Summary By Aaron J. Seigo

Topics: KOffice, Filters

People: Waldo Bastian,�Dom Lachowicz,�Werner Trobin

One important aspect of Free software is open collaboration and the pooling of efforts. There are several open source word processors available and they all need to import and export the ubiquitous MS Word format. To try and avoid duplicating efforts, developers from the Abiword, wvWare and Kword projects have been talking with regard to pooling their efforts in writing filters. Shaheed Rhaque had noted that based on his experience of looking at Abiword and Open Office filter mechanisms that there probably wasn't much actual code that could be used between the projects. However, Waldo Bastian said, " Myabe it's usefull to have a small mailinglist that can be used to exchange information about the pecularities of certain formats. The code might be different, but the problems that it faces are still the same of course."

Dom Lachowicz from the Abiword project replied saying, " I'd love to set something like this up, and there are people on both the wvWare and AbiWord lists that'd like this a lot too (and Mattias Ettrich too). So here comes the all-important question: my server or yours? I personally don't care and will be happy with whatever you guys choose. If you create a list, please tell me so that I can subscribe to it and get the word out to other interested parties. I'd suggest a neutral name like doc-devel@<someserver>.com. If not, I'll just set up doc-devel@abisource.com" Dom also invited the other developers to an IRC meeting.

Werner Trobin managed to meet up with Dom on-line and reported,

We talked a little about the basic problems we have (which libs we can depend on, which language,...) and we found out that we have quite common thoughts about all that.

We came to the conclusion that it might be the best idea to have a mailing list office@freedesktop.org (see http://www.freedesktop.org) and he said he'll ask hp to create it.

Meanwhile all people interested in developing this library should please create a sourceforge.net account and as soon as the list is set up we can start to talk about the basics in more detail :)

He was in favor of writing the library in C++ and to provide C interfaces for the most common tasks.

With this kind of cooperation between the projects we can only hope to see them move ahead even faster.

2. Address Field Autocompletion in KMail

23�May�2001�-�24�May�2001 (7 posts) Archive Link: "address completion"

Summary By Aaron J. Seigo

Topics: Auto Form Completion, KMail

People: Carsten Pfeiffer,�Christian Tiberna,�Michael H�ckel

Autocompletion: Konqi's location bar has it, web form text fields have it, the open file dialog has it, the quick launcher has it ... and now KMail address fields have it. Carsten Pfeiffer posted a patch and said, " here's a quick patch that adds {auto,short-auto,popup,shell}-completion support to kmail's composer. Not sure if the From and Reply-To edits should use the same completion-items as the others tho (or at all). Currently, the entire address is completed/shown, not just the name without email-address (a la Outlook). I would need some input if we want that, or not and some more information about how it works. Does completion in Outlook only work with names, or also email-addresses? Does it resolve email-addresses to names? I need some use-cases, if we want that."

Michael H�ckel and Christian Tiberna both reviewed, tested and mentioned minor issues with the patch. The issues were addressed and it was checked into CVS.

3. Fixing Crashes Due to Bad Config Files

23�May�2001 (10 posts) Archive Link: "qdatastream with checksum"

Summary By Aaron J. Seigo

Topics: KConfig, Bug Tracking

People: Simon Hausmann,�Rik Hemsley,�Waldo Bastian,�Nikolas Zimmerman,�Rick Hemsley

For a system to be perceived as being robust it needs to be fault tolerant. This world isn't perfect and there is a lot of bad data out there that our computing systems need to be able to handle gracefully. On this topic, Simon Hausmann posted to the core-devel list saying,

Recently Waldo fixed the dcopserver to handle possibly corrupt data better. (I had a crash because of this, twice) Just 15 minutes ago a friend here in the uni had a crashing konqueror because of a corrupted konq_history file.

What's the common thing? Both (konq/dcop) use QDataStream to marshal data and demarshal it without any checkings. This can result into errors like an attempt to demarshal a QString with the length of 5124361243561 bytes (which makes us end up in a nice malloc() call :-) , just because the length byte (or the data in general) was corrupted.

Sure, we can't recover from corrupted data, but at least we could bail out if we would have a way to check the consistency of the data before starting to extract and interpret data out of it.

So how about using checksums to check the correctness? It is for sure nonsense to add a checksum for each and every object, but how about doing it once for the whole chunk of data?

What I'm thinking of in detail is a KCheckSumByteArray (TODO: find better name :) , which inherits from QByteArray and adds a checksum property (like we could use a simple CRC32) when being marshalled into a QDataStream (and does so likewise when reading from a QDataStream, including a check of the checksum and setting a isValid() boolean property appropriately) .

Simon also volunteered to code this functionality. Nikolas Zimmerman was concerned about how this would effect performance, to which Rick Hemsley said succinctly, "CRC32 for 1M of data on PIII Celeron 600 takes 14ms." Waldo Bastian asked Simon, "Do you want to use KCheckSumByteArray as source for the QDataStream or do you want to feed KCheckSumByteArray into the datastream? I think you need the first." Simon replied that he did indeed plan on hacking the check summing class be the source for the data stream, but that it would also contain operators for feeding itself into and out of a QDataStream.

With this functionality in place, corrupt configuration and data files should be less of a problem in the future for KDE.

4. New Autoconf Version Breaks KDE Build

23�May�2001�-�26�May�2001 (17 posts) Archive Link: "Autoconf 2.50 breaks KDE builds"

Summary By Aaron J. Seigo

Topics: Building KDE, Debian

People: Ben Burton,�Dirk Mueller

Debian recently updated autoconf (one of the programs that helps automate build configuration) in their development branch to version 2.50. Ben Burton posted to the list saying that this broke the KDE build system. Bernhard Rosenkraenzer suggested using the autoupdate tool, but Ben reported having no success with this. Dirk Mueller then posted a patch asking for people to test it, to which Ben replied, " I started tinkering last night.. I tried that. Then you get a couple of circular dependencies (A depends on B which actually expands to use A). After removing the appropriate AC_DEPENDS lines it will then start trying to create ./configure which is good news. I have attached the patch that fixes these problems below; this improves things with autoconf 2.50 and doesn't seem to break autoconf 2.13." Ben noted that he was still having problems though. After going back and forth on and off the lists regarding the autoconf issue they managed to finally track down and fix all the issues The final changes were committed to CVS and should therefore be in the 2.2 release.

5. Konsole's History: Closer and Closer to Getting it Right

25�May�2001�-�28�May�2001 (9 posts) Archive Link: "konsole's history : is anyone taking care of it ?"

Summary By

Topics: Konsole

People: Guillaume Laurent,�Stephan Kulow

Guillaume Laurent volunteered to take care of restoring Konsole's history capabilities saying, "It seems that konsole's 'history' feature has been disabled for a while now. I suppose this is because of the hist. files ever growing and taking up all space in /tmp. I'd like to try to fix that, but before I want to make sure that nobody is working on it. What I would like to do is move the current history to a file logging feature (like xterm had) and add a simple fixed-length, buffer-based history instead."

Guillaume posted a patch shortly thereafter. Stephan Kulow replied soon after saying "I worked on " [konsole history] ", but the problem is that konsole has currently no concept of throwing history away. It has only two modes: either all history or none at all. If you can code that, we could then readd that code around BlockArray as I find it very useful to have a bit more history than available in xterm." Guillaume said that this went far beyond what his current patch was doing and wasn't sure if he'd have time to implement this, but then soon posted a second patch using BlockArray saying "Given that nobody expressed interest in file logging and it looked like a headache to get right (from the user's standpoint, that is, how to select the file name), I went ahead and used your BlockArray instead. I had to make a couple of changes, you might want to check (see in BlockArray::at(size_t i))." Stephan found a few remaining issues that needed attending to before it was ready for CVS.

6. Konqueror's Sidebar Revisited

26�May�2001�-�27�May�2001 (10 posts) Archive Link: "FWD: RE: FWD: A question about konqueror"

Summary By Aaron J. Seigo

Topics: Konqueror, UI

People: Jonathan Lee,�David Faure,�Carsten Pfeiffer,�Joseph Winninger,�Joseph Wenninger

Jonathan Lee and David Faure had been having an ongoing conversation off-list regarding the side bar in Konqueror as Jonathan and some of his friends want to help make the sidebar more on par with what is seen in other new file managers, such as Nautilus. However, being new to the Konqueror sources Jonathan asked David, " Do you know who was spearheading this idea? I'd like a status update from them. My friends and I talking about doing this would prefer that a _core_ Konqueror developer were to implement the extension of the side bar to insure that is is _sane_ and non-conflicting with the rest of the program, while we work on an assortment of tabs. Failing this I guess we could do it all, but I wouldn't hold breath over its completion, we won't be doing anything to Konqueror this invasive until we've poured over the source enough to be fairly sure we're not going to break a lot in the process." Being a fair request, David forwarded the bulk of the conversation to the kfm-devel list and asked, " Carsten, what's the status of the tabbed sidebar ?"

Carsten Pfeiffer replied saying,

I'm glad there is interest in the sidebar! At the moment, Jelmer Feenstra and a friend of him are working in it, AFAIK. Jelmer, are you subscribed to kfm-devel?

I don't have the time to work on it myself right now, but I'll gladly assist in design or any other questions. I might find the time end of next week to help coding.

Maybe it would be a good idea to define the interface of such a plugin for the sidebar? It surely will have to be refined later, but it would give you a start to write plugins before the sidebar is ready.

I'm also interested in a search-component, where you can search for all kinds of things (I wrote the kmrml plugin for Konqueror which lets you search for images by their content, utilizing the GNU Image Finding Tool (GIFT)).

Jelmer Feenstra replied, albeit only to Carsten by mistake, saying that while he had done some work on it he still had a lot of design questions left unanswered. Jelmer recommended a meeting on IRC to discuss the issues. Carsten, while passing on the message to the list, also said, " I think the sidebar will be redone -- the current one will actually become a plugin for the new one. Have a look at http://207.44.242.45/~qwertz/sidebar3.html for some ideas how the sidebar should work." .

Joseph Wenninger spoke up at this point saying, " I'd like to contribute to the next sidebar. I think qwertz's mixture between mozilla's/ie6's bar looks quite nice, I'm going to try to implement it (some test code), or does someone else have a good idea how it should look like or does someone already have code ? I think the plugins should be quite lowlevel, not even kparts, i think this would be too much overhead for this purpose. If a plugin really needs to show a kpart, eg html or so, it should load it itself. It thinkt the simplest, easiest and best way is, to make an abstract pluginclass which inherits from a simple QWidget." Jelmer Feenstra replied that he had started putting together a basic framework for this but needed more input. Joseph also committed some code to CVS that would enable the docking of individual widgets into the new side bar very simple.

It looks like Konqi's sidebar is getting the attention it needs now and we look forward to seeing it grow and mature in CVS.

7. New 3D Modeling Application in CVS: KPovModeler

28�May�2001 (19 posts) Archive Link: "New project in CVS: kpovmodeler"

Summary By Aaron J. Seigo

Topics: New Application, Multimedia, Art

People: Andreas Zehender

If you are both a KDE and a POVRAY fan: brace yourselves. Andreas Zehender announced to the list that he checked in a new application called KPovModeler saying,

I just imported a new project into the CVS: kpovmodeler. KPovModeler is a modeler for povray scenes for KDE. This program isn't fully functional but useable yet. Only the framework is finished.

Current features:

Currenty, there are 27.000 lines of code (inclusive comments), several classes (all documented with kdoc). It is a clear framework so that new povray objects can easily be added. The program makes use of the KParts framework.

See http://www.azweb.de/kpovmodeler for screenshots.

Now that the framework is finished and the sources are imported into the KDE CVS tree, I am looking for developers to join the project. Send me a email if you are interested. Give the program a try and let me know what you think of it.

NOTE: The program reqires the QT OpenGL module.

There was some technical discussion regarding Qt's OpenGL implementation requiring thread support to be built as well as some apparent bugs in KPovModeller's display. There is already a good amount of code in this project and will undoubtedly be embraced by the 3D modeling fans out there.

8. A new home for the Dot

29�May�2001 (9 posts) Archive Link: "[kde-promo] The Dot"

Summary By Rob Kaper

Topics: dot.kde.org

People: Navindra Umanee

Many friends of KDE often check The Dot (http://dot.kde.org/) for updates on their favorite desktop environment. However, this excellent news site experienced severe downtime last week resulting in the question whether it should be hosted elsewhere.

Navindra Umanee explained such a change would be "a decision that would have to be collectively made by the editors, and we would have to have a good offer to consider" . He continued: "If we move, we would have to move to someone who's a KDE friend, is willing to accomodate our needs, and who also has a reliable network."

Bernhard Rosenkraenzer made an offer to run the site on bero.org, which apparently met all the requirements because two days later Navindra had already transferred the site and posted (http://lists.kde.org/?l=kde-promo&m=99135107908202&w=2) :

The server, though controlled by Bero, is hosted on the europe.redhat.com network and UPS, and we have several contacts for server admins. The DNS has been updated to reflect the changes, and we are getting many hits already.

9. KPresenter and Autosave

29�May�2001�-�30�May�2001 (6 posts) Archive Link: "KPresenter sloooooww..."

Summary By Aaron J. Seigo

Topics: KOffice, Performance

People: Pascal A. Niklaus,�David Faure,�Werner Trobin

Pascal A. Niklaus posted to the koffice-devel list saying, " Yesterdays KPresenter as well as KPresenter from the KOffice 1.1 beta2 are *very* slow compared to KPresenter 1.0. Sometimes the GUI hangs for 5 seconds or even more, without obvious reason. I wondered whether this is a configuration problem ? Or is this a known issue ? I'm running KDE 2.1.2 on a 500MHz P III, w/128MB RAM, and the system is otherwise reasonably fast..." Pascal later admitted that he had a presentation to do in front of a large crowd the next day and had committed to doing it in KPresenter rather than Power Point and really wanted it to go smoothly.

David Faure said, "Hrmm... that's the autosave feature...... For big kpresenter documents it's indeed a problem... And there's no config for it in kpresenter yet. Either this should be added, or it should be turned off completely I guess (kpresenter is quite stable, didn't get a crash in a *very* long time)" This prompted discussion between Werner Trobin, Toshitaka Fujioka and David on how to make the autosave feature faster and more efficient. This resulted in some excellent ideas which are slated to be be implement in KOffice. A patch was also posted for Pascal's sake as a short term fix for his problems. Pascal applied the patch, compiled, presented and reported great presentational success the next day.

Of course, telling people to patch their applications isn't a viable long-term approach. Three days after Pascal's initial post Toshitaka posted a patch that allowed autosave to be configured from the Settings dialog. The patch was committed to CVS the day after that.

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.