Kernel Traffic
Latest�|�Archives�|�People�|�Topics
Wine
Latest�|�Archives�|�People�|�Topics
GNUe
Latest�|�Archives�|�People�|�Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

KDE Traffic #4 For 31�Mar�2001

By Aaron J. Seigo

Table Of Contents

Introduction

Welcome to KC KDE! This week saw the release of KDE 2.1.1, progress in the printing subsystem and even a discussion on reintroducing CORBA into KDE. As the KDE2 series gains greater maturity the developers can be seen looking both at the minutiae that remain to be taken care of as well as the larger picture. Big questions were asked this week along with a profound amount of detail work.

Here are the highlights of this exciting week. Happy hacking!

1. KDE 2.1.1 Release

20�Mar�2001�-�21�Mar�2001 (10 posts) Archive Link: "KDE 2.1.1 release on its way"

Topics: Release Schedule, KDE 2.1.1

People: David Faure

David Faure announced to the list: " I'm tagging the modules right now, so don't make any more commits to the KDE_2_1_BRANCH unless really necessary, and drop me a mail if you do." With little further ado KDE 2.1.1, which consisted largely of bug fixes to the 2.1 release, was bundled and released.

2. KDEPrint Development

22�Mar�2001�-�24�Mar�2001 (6 posts) Archive Link: "KDE printing stuff update"

Topics: Printing

People: Michael Goffioul

The new KDE printing subsystem continues to evolve. Michael Goffioul reported his progress to the list, noting the major adjustments since the inception of the new library as: "

  1. Plugin architecture
    The code structure is now based on plugin mechanism. A core library define a framework, and the real printing job is done in dynamically loaded plugins. There's no dependency problem anymore.
  2. KPrinter class compatible with Qt mechanism
    One a the major drawback of the previous code, was that the KPrinter object was a singleton created by a factory. This has been changed. The factory is hidden and the KPrinter class can be used exactly as QPrinter class. So the porting effort should reduce to replacing 'Q' by 'K'.
  3. New printer management tool
    As I explained in previous mails, I extended the printing stuff to the development of a generic printer management tool. This tool has the form of a KControl module whose GUI is similar to KUPS. This tool allows to list, add, remove, configure, ... printers. Add operation is made through a powerful and easy-to-use wizard. Modules (management, and print system selection) are now installed in "System" section.
  4. Library splitting
    The library has been split into a core part and a management part. Applications need only to be linked against core library. This has been done to reduce startup time of applications.
"

Elsewhere in the thread Michael noted that only a few printing systems are supported and that the entire system is rather untested. Many of the KDE applications have begun porting to the new print system in anticipation of its eventual maturation.

3. CORBA and ORBit in KDE?

26�Mar�2001 (17 posts) Archive Link: "Future of DCOP"

Topics: Development Language, DCOP

People: Matthias Ettrich,�Cullman Cristoph,�Dirk Mueller,�Waldo Bastian,�Lotzi Boloni

It is well known that KDE decided to abandon CORBA-based interprocess communication during the early days of KDE2 development. It was therefore something of a surprise when Matthias Ettrich posted to the list, saying:

I've done some thinking about DCOP recently, under the lights of the ongoing problems with libICE on platforms other than Linux and the fact that it's unmaintained.

Thinking about alternatives, there are really just two options, ORBit and MCOP.

Given that MCOP is meant for multimedia and that we eventually will have to or want to utilize ORBit anyway in the future for all kinds of desktop cooperation (accessability, session management (XSMP over ORBit rather than ICE), network directory services, ...), I'd like to evaluate porting DCOP over to ORBit as underlying communication layer.

DCOP is a nifty ipc solution based on standard X11 and libICE is definitely fixable. But I really care more about semantics and ease of use than the binary format on the network. Replacing libICE with ORBit should be straight forward - almost. The only technical problem I see right now is for the DCOPServer to safely detect when a client goes down. I hope this is solvable, if not by adding something to ORBit. I haven't checked this yet.

Opinions, flames, suggestions?

Cullman Cristoph was the first to respond saying, " I have used sometime ago GNOME gnorba stuff (using ORBit) and I see no problems in the speed sector, ORBit is really a fast orb - > good replacement. Using ORBit seems to be a good idea, because GNOME uses it too (why there should be 2 implementations of the same thing)."

Not everyone was quick to accept the idea however. Dirk Mueller asked: " what advantages has orbit on the technical side over ICE ? I mean, does it use a faster way of interprocess communication than sockets / pipes ? does it use less memory ? will the dcopserver process be obsolete then and be replaced by orbit ? Is orbit useable without having to use the CORBA marshalling ? will it be possible to easily integrate the qt <-> CORBA marshalling for easy interopability with gnome apps ?" Dirk added that if none of these questions were answered with a "yes" then it wasn't worth it in his opinion. Matthias responded listing the following three benefits: "

  1. Maintained.
  2. Gives access to CORBA interfaces.
  3. Opens room for cooperation.
" The issue of libice not being actively maintained is an especially poignant point, to which Waldo Bastian pointed out: " I rather fix the code than blame others. That is why we are currently using a fixed ICE. I know that ICE pretty much serves our need I have no idea what the problems with ORBit are going to be and it will costs us a long time to find it out." Waldo added to this in another email saying: " At this point in time I think it is a really bad decision to change core parts of our architecture. We need a stable platform much more than these kind of changes for the sake of change. We don't need this." Stephen Kulow agreed with Waldo on this point.

Lotzi Boloni asked, " Who are the current Orbit maintainers, Eliott Lee, Havoc? Maybe they should speak up (they are surely listening). It would certainly require a commitment from their part, to accommodate the needs of two projects." No correspondence from either ORBit author was heard.

4. KDE2.2 Multimedia Meeting

20�Mar�2001�-�23�Mar�2001 (5 posts) Archive Link: "KDE2.2 Multimedia Meeting Summary"

Topics: Multimedia, Meeting, aRts

People: Stefan Westerfeld

Stefan Westerfeld announced an online meeting of KDE2 multimedia authors saying, "As in the past I'd like to do a brief meeting for making a list of goals we want to achieve in the multimedia department for the official KDE2.2 release. This will provide a good way to synchronize developments. The goals should be defined by the *developers* actually implementing them, so that it will provide a realistic plan what will really happen, not some random collection of wishes. If you have written at least 1000 lines of multimedia related code which has been released with any of the previous KDE versions, or want to write at least 10 new lines of multimedia related code which you intend to be released with KDE2.2, consider yourself invited ;-)."

The meeting was a success with fourteen attendees and focused on aRts, the multimedia daemon of KDE2. Topics such as making aRts multithreaded, safe error and exception handling, using KIO in aRts and integrating kmix and aRts were discussed. The KIO integration is particularly exciting since it would give aRts the network transparency and flexibility that has been such a large factor in Konqueror's success and popularity. Also discussed was a mechanism for describing toolkit-independent GUIs for aRts objects. Stefan covered this in his summary of the meeting saying:

Often, aRts objects (like the freeverb effect) will need a GUI. The GUI should be sharable between artscontrol and noatun (and other possible aRts aware apps). An important design restrictions to meet is, that it should be possible to keep effect GUIs toolkit independant.

So the idea for KDE2.2 might be having a "factory interface", which provides a way to obtain a GUI for a given effect (like Arts::Synth_FREEVERB). This factory might

For the first two cases, this will be toolkit independant. Arts::Widget, Arts::Panel, Arts::Poti and so on are interfaces.

There is a "Requires=kde_gui" line in the implementation (.mcopclass file), so the Requires/Provides mechanism of MCOP will be able to select a fitting one for each application (i.e. Gtk version for Gtk apps). The GUI will be built inside the client application and thus be able to interact with the application toolkit in a natural way.

Of course, the whole GUI issue will not only be useful for effects, but also for PlayObjects (configure interpolation quality of the mikmod .xm engine), Instruments, and all other kinds of objects.

It will be exciting to watch aRts mature and gain further polish.

5. How fast does KDE start?

21�Mar�2001�-�23�Mar�2001 (5 posts) Archive Link: "Tuning KDE startup performance ?"

Topics: Performance

People: Pavel Troller,�Matthias Ettrich,�Mathias Waack

Pavel Troller reported his findings on the startup time of KDE2 saying: " I'm still unsatisfied with the speed of KDE startup process. On my new machine, running Thunderbird on 918/102MHz (light overclock) and 512M of 133MHz RAM, KDE startup takes exactly the same time as on a substantially weaker one, with K6/2 on 450 and 128 M of 100 MHz RAM. Especially "Setting the interprocess communication" and "loading the window manager" phases are really sloooooooow! After being up, KDE is surprisingly fast."

Matthias Ettrich explained that what Pavel saw in the start up screen was misleading, saying, " The splash screen texts do not indicate everything that's happening in between. When it says "Setting the interprocess communication" a lot more things happen, including loading most of the KDE libraries in memory. When it says "Loading the window manager", several other processes are starting up at the same time: kdesktop, kpanel, all in autostart, etc. I really don't like it that both dcop and kwin get the bad press due to a missleading ksplash :-( Kill kwin on your machine and restart it: it takes less than one second." Mathias Waack suggested making the splash screen give more detailed information on the start up process to help combat these common misconceptions.

6. KDE Developer's Checklist

22�Mar�2001�-�24�Mar�2001 (4 posts) Archive Link: "KDE Developer's Checklist"

Topics: HowTo

People: Jeff Tranter

Jeff Tranter announced to the list a documentation project he had undertaken, saying " There are a number of things that are easy to overlook when working on KDE applications. I thought it would be useful to put together a checklist of development items. My intention is to put this up on developer.kde.org although it might make sense to put it in the KDE Developer's FAQ instead. I'm looking for feedback on whether this is useful and if there are any more items that should be added or corrections to be made."

After brief discussion, Jeff announced that the checklist had been uploaded and could be found at http://developer.kde.org/documentation/other/checklist.html. Several items for addition to the checklist have been discussed since its announcement. This looks to be a good resource for new and experienced developers alike.

7. Poor performance of GNU malloc()

24�Mar�2001�-�25�Mar�2001 (7 posts) Archive Link: "Special purpose malloc() in KDE?"

Topics: Performance

People: Petter Reinholdtsen,�Rik Hemsley

While doing some performance testing, Petter Reinholdtsen noted the less than stellar performance of the GNU malloc() memory allocation routines. He reported this saying:

The last few days, I've been checking the perforance of GNU malloc (glibc v2.1.3 in Debian 2.2), and was shocked to discover how bad it behaved in our application. The memory usage was almost stable on ~2 MB, bu the process size was increasing several megabytes, starting at 15 MB, and eding above 30MB. Using the mallinfo() stats, I discovered the amount of free memory increasing instead of being reused. I expect this is due to bad memory fragmentation.

Replacing the malloc() implementation with Doug Lea's malloc(), available from http://g.oswego.edu/dl/, changed the situation completely. The process size stayed stable around 17MB, and the amount of free memory rarely moved above 200KB.

Rik Hemsley attempted to verify Petter's findings by comparing GNU malloc() with Doug Lea's malloc() in his own program Squelch, which is an Ogg Vorbis audio player. He reported between 7% and 8% improvements in memory usage with Doug Lea's malloc().

It would indeed be interesting to see what the overall impact on the entirety of KDE would be if this new malloc() was used everywhere.

8. Konqueror in a Dial-up Environment

22�Mar�2001�-�27�Mar�2001 (4 posts) Archive Link: "konqueror cache/off line browsing"

Topics: Konqueror

People: Waldo Bastian,�Tobias Anton

Francois-Xavier Duranceau wrote in noting that Konqueror did not make a very good off-line browser since it always tries to verify pages originally loaded from the network, even if the machine is no longer online. This can be a problem for those with dial-up accounts. Waldo Bastian noted the solution to this saying, " we have the following cache control options:

See http.cc:2180. We just need to make it possible to configure the default then. This might be a nice job for someone who wants to start coding for konqueror."

Tobias Anton volunteered to implement this, asking only to be pointed in the right general direction.

9. And in this corner... we have IMAP!

24�Mar�2001�-�25�Mar�2001 (9 posts) Archive Link: "kmail wishlist/bugs"

Topics: KMail

People: Michael Hackel,�Richard Box,�Richard Bos

An enormous amount of work has gone into providing quality IMAP support in KMail over the last few weeks. Carsten Pheiffer posted a patch to the kmail list that fixed several detail issues. Carsten also noted that he had never had an opportunity to use IMAP himself. Michael Hackel replied saying, " I just wonder how many people really use IMAP as it is supposed to be by storing really all mails on a server. Everywhere people cry for IMAP support and somehow consider KMail not as a real e-mail client as long it does not support it, as again mentioned as the main lacking feature in a recent linuxorbit story. At least I don't know even one person personally who uses IMAP... Also people complain about KMail being slow with huge folders, switching between huge IMAP folders is surely _much_ slower independant of the client."

This was quickly replied to by several who used IMAP in their place of work. This included Richard Bos who noted the sheer numbers of people who do require IMAP support on a daily basis, saying: " I think the number can climb up to 10.000+ people at the company where I work... And because there is not a decent imap email agent in the kde environment, netscape needs to be used."

A technical discussion ensued debating the merits of POP3 vs IMAP. At the end of it all, however, it was undeniable that many do use IMAP and that support for this common protocol, despite it not being used much by the developers, is necessary for KMail to reach as wide an audience as possible.

10. KWin Themability Improvement Efforts

24�Mar�2001�-�26�Mar�2001 (4 posts) Archive Link: "KWin configurability, and more kwin styles..."

Topics: Look and Feel

People: Karol Szwed

Karol Szwed, normally a very quiet but determined coder, poked his head into the kde-look list and announced:

I have a few goodies I'd like to notice people of, such as my new Quartz kwin client for kwin. Take a peek at http://gallium.n3.net/ (which desperately needs updating, I know :) This missed KDE 2.1.1, but will be in KDE 2.2 with any luck, and is in the cvs HEAD branch. It will become much more configurable in future, such as replacing the block transition with gears (via a user option), and other nifty configurable features.

I have already taken some small steps into making kwin clients (or decorations) customizable and user friendly, such as adding toolwindow support into quartz and win2k clients (with more on the way of being converted), and am looking into adding customizable options for kwin clients like window button tooltips, gradient types, titlebar/window border sizes (for accessibility purposes), button positions, etc etc. We need input into what's most needed/requested and in which clients :)

In future, if time permits, I will try to create a scriptable kwin client in the light of sawfish/enlightenment/icewm etc. storing scripts in a compressed XML format. (Yes, kde.themes.org rejoice. At least we're talking about one now :) A bit like the current kwmclient, but not as cumbersome or KDE1 oriented - much more flexible and powerful.

Karol also noted that he intends to wrap the various theme related KControl modules into a more coherent and interoperable set of controls, making coordinating the many pieces of KDE themeing easier. Also Of special note is Karol's mention of a scriptable kwin client. Themes have been slow to appear for KDE2 relative to other window managers due to the lack of an easily sriptable theme engine. Karol wants to change this with a native KDE2 scriptable theme. In the mean time, in addition to Karol's native KDE2 decorations, he has developed an as-yet-unreleased, but fully functional, icewm theme importer for kwin.

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.