KDE Traffic #15 For 22�Jun�2001

Editor: Aaron J. Seigo

By Aaron J. Seigo �and� Rob Kaper

Table Of Contents

Introduction

Welcome to KC KDE! This was the week that the 2.2beta freeze ended. It was a fairly long freeze for a beta, but one that was definitely needed. Due to the nature of the development that occurred during the freeze there wasn't much in the way of interesting discussion to cover in the weekly summary. That isn't to say there wasn't a lot of development or activity on the lists. There was a lot of both, but it tended to be of the "boring" sort: bug and compile fixes. This is exactly why freezes are so important to a large project: without them, much of this boring work would be overlooked. Of course, KDE is still in a general feature freeze pending the release of 2.2

Also this week the "Mosfet Scenario" came to a conclusion. Rob Kaper took on the task of summarizing the sometimes heated and often confusing discussion that occurred and rocked, if only for a short time, the KDE development world. Thankfully it seems things are back to normal and we can look back on what happened with some perspective.

Enjoy the summaries and happy hacking!

1. Mosfet's code is dead, long live Mosfet's code!

20�Jun�2001�-�21�Jun�2001 (6 posts) Archive Link: "Maintenance of Mosfet's KWin and Widget styles"

Summary By Rob Kaper

Topics: Look and Feel, Art

People: Neil Stevens,�Karol Szwed,�Michael Matz,�Rik Hemsley,�Rob Kaper

(ed. [Rob Kaper]

Initially issue 14 (http://kt.zork.net/kde/kde20010615_14.html) of KC KDE would have covered the announcement of the new Liquid style by Mosfet (Daniel M. Duley), but it has probably not gone unnoticed that the situation ignited, unfortunately at the same time as my deadline to cover it.

I would either have to leave those events out and write a summary already outdated on the moment it would be published. Or I could include them but only include some of the earliest posts, leaving more questions than answers, a lot of room for flamebait and incomplete or partial arguments.

Therefore I decided not to cover it at all for last week, I believe the issue has been covered enough in various places already and my personal opinion isn't much more than "ok, Mosfet and KDE don't get along anymore, that sucks, now let's move on and get back to coding".

)

The very short story is:

The situation did not resolve itself. Mosfet felt criticized and others felt that he should give in a bit because for the benefit of the masses (the KDE users).

Because some of the code Mosfet contributed to KDE are critical parts for a release such as his KWin and Widget styles, the KDE project has forked this code while Mosfet will still develop his own versions and release them separately.

Neil Stevens wrote: "I just found out, to my surprise, that I volunteered to do the System++ style. That's fine by me, I'll take it and add to it what it needs, but it shows there's a little confusion going on. Do we know who's taking over for Mosfet for maintenance of the various things of his that are remaining in cvs? Perhaps it's a good idea if we just spell out here who's doing what, so that we don't get any nasty surprises later on."

An answer was provided by Karol Szwed:

Currently from what I know the following is happening, which may be subject to change:

KWin style Maintainer
==============================
b2 - Michael Matz
system++ - Neil Stevens
riscos, web - Rik Hemsley
laptop - lenny and myself
default, win2k, quartz, icewm, modernsys - me
kde1 - Not sure about this one, probably me

Any others I haven't listed are free for volunteers - if there's no interest, I'll maintain them. I do not know about what's happening with kstep.

Does not having kwmtheme break the theme stuff?

Kstyles
=======
highcolor and locolor default - not sure yet
megagradient - Ralf delegated this one to me
web - Rik Hemsley
klegacy - I know who doesn't want to maintain this ;)
any others - not sure yet

People who worked on these styles and are still interested, please let me know - if not, I'll probably maintain them for now.

While the list of new maintainers is not complete yet and subject to change, it looks like this is still a happy end as far as the KDE users are concerned. Upcoming KDE versions will continue to include their favorite styles and Mosfet can release the fruits of his creative skills, without having to face restrictions that come with being part of a larger whole.

2. KDE PIM Developers Switch Gears

13�Jun�2001�-�16�Jun�2001 (19 posts) Archive Link: "KDE PIM Roadmap (Call to action)"

Summary By Aaron J. Seigo

Topics: KDE PIM

People: Mike Pilone

KDE2 has been racing ahead on just about every front. However, not every application or library gets the same amount of time paid to it. This is often because the people maintaining that part of KDE2 have real life responsibilities that preclude them from spending as much time as they would like to hacking on their pet projects. One area that has especially suffered from this is the KDE2 PIM package. KOrganizer has been moving ahead as has the KPilot palm pilot sync program. However, the KDE2 PIM developers felt that there wasn't enough forward movement happening and that the kdepim module was simply not keeping pace with the rest of KDE2 development. To address this, Mike Pilone wrote a "KDE PIM Roadmap (Call To Action)" as follows:

I was recently talking with Greg Stern (of abbrowser conduit fame) about the state of KDE PIM. In our discussions, we started to through around some ideas of redesigning the entire KDE PIM API.

I spent a few hours the other day brain storming and writing down my ideas. Most of these ideas are things I have seen as points of concern for the KDE developers.

My ideas are far from complete, but I hope to excite the imagination of the current developers. I am aware that some work in this area has already been discussed (relayed to me through Greg), and I am interested in collecting all of those ideas. I will not pretend to have all the answers, but we have to start someplace

.

Ideally, I would like to write up the roadmap for KDE PIM, to help guide the interested developers in the right direction. If all goes well, this would culminate in a PIM developer gathering in late 2001 (September/November timeframe). With this preassembled roadmap, the meeting can be a codefest, to try out our proposed ideas and quite possibly have a new PIM architecture in place, rather than design meetings and methodology arguments.

I think that currently KDE is lagging behind in the PIM area, and I hope to contribute not only ideas and guidance, but as much code as possible! This is no fault of any one person. The current PIM developers are doing an excellent job, and I praise them for their work.

If you are interested in this area of KDE, please take a look at my work in progress design overview at http://www.slac.com/~mpilone/kde_pim_api/

I am really interested in feedback from PIM developers, especially those who may have already been working on solutions to problems. I want to pull everything together so the PIM package, and KDE as a whole, can be as strong as possible.

Thanks for your time. Comments, suggestions, and questions are always welcome at mpilone@slac.com.

This email inspired a large amount of positive discussion from the developers involved with the various parts of KDE PIM, along with some new faces. Storage mechanisms, address book architectures, data sharing, XML formats, conduits for handhelds and more were discussed in great detail. If even a fraction of what was being discussed sees the light of day, KDE2 users should end up with a brand new PIM architecture that will be very flexible and powerful. Of course, reporting on things that haven't occurred yet isn't the best policy. So as developments unfold and proposals become reality in the KDE2 PIM world KC KDE will strive to give comprehensive coverage of the events.

3. Multithreading in KDE?

16�Jun�2001�-�17�Jun�2001 (27 posts) Archive Link: "Multithreaded application development"

Summary By Rob Kaper

Topics: KIO

People: Aur�lien Gateau,�Cristian Tibirna,�Waldo Bastian

Aur�lien Gateau wrote in: "I'm writting a KDE application which could really benefit using threads. I wanted to use Qt-mt, but I read that it was not possible since KDE currently doesn't link against Qt-mt." and asked "I would like to now what is the current politic regarding threads in KDE applications ?"

Various people responded, some explaining how to use threads in an application and others advocating that one should not want that in the first place. Cristian Tibirna explained why KDE does not use threads at the moment and how Konqueror can still respond to user events while also downloading data from the network, without threads: "KDE uses a technology called KIO (KDE's input/output technology) to accomplish this. These use the "many processes" as opposed to "one process/many threads" approach. There is a continuous religious war about processes vs. threads efficiency and performance but for now we don't care about this. Qt's support for multithreading is very young and (perhaps) still fragile. We will wait for it to mature (heard Qt-3 does it) and then we will start using threads more than currently, as Waldo says."

Waldo Bastian responded:

Sorry, I'll have to pedantic here: I haven't said that we will be using threads more. My first answer to threads is, and always has been: don't.

Having said that, I do that there are cases that threads might be the proper solution and I don't think we should deny _other_ people the possibility to use them in such situations.

A general discussion on multithreading continued for a while and Aur�lien received more help and hints to accomplish his task without using Qt-mt.

4. Old Applett, New Hands: The KNewsTicker Torch is Passed

18�Jun�2001�-�20�Jun�2001 (8 posts) Archive Link: "KNewsTicker - anyone?"

Summary By Aaron J. Seigo

People: Frerich Raabe

Most programmers know the feeling of having been around a project too long: the problem space doesn't feel sexy anymore; there aren't any new features that you really, really, really want to add; staring at the same code for what seems a very long time is getting really stale. The primary coder of the applet that comes with its own integrated desktop, KNewsticker is no exception to the rule. Frerich Raabe posted to the list looking to pass the torch on saying:

just wanted to ask whether anybody here is bored and feels sufficiently motivated to become the maintainer of KNewsTicker. I've been working on it for a few months now, and it was quite fun, but I noticed that I more or less have to force myself working on it lately. It's quite boring since a few weeks, especially since the program evolved beyond the point I originally wanted it to grow to.

Don't get me wrong, I would maintain it if nobody else wants to do so, but I think a new maintainer with fresh ideas might be a better thing than a burned out hacker who just doesn't want to see an otherwise nice applet go down to the dumps.

it would be cool if I could find some motivated hacker who would volunteer to work on the news ticker from now on (so that I can force my energies on a new project), otherwise I'll just have to force myself to do so.

Of course, this is exactly the type of opportunity that is perfect for someone looking to get a start in KDE development. A few people replied saying they would love to spend their limited free time maintaining and perhaps even extending KNewsTicker further. All the KNewsTicker users await their efforts and the ongoing evolution of this very popular applet.

5. Using GCC3 to Compile KDE2?

18�Jun�2001�-�20�Jun�2001 (24 posts) Archive Link: "KDE and Gcc 3.0"

Summary By Aaron J. Seigo

Topics: GCC 3, Building KDE, KDE 2.2

People: Mathieu Chouinard,�Nils Holland

GCC3 was released this week. For those writing programs in C++ this was a much anticipated release as it promises better standards compliance, better results, and a stable ABI among other things. The day GCC3 was announced Mathieu Chouinard asked, " Does anybody have compiled KDE 2.2alpha2 with GCC 3.0?"

Nils Holland reported his limited success with GCC3 saying, " I just put GCC 3 on my test machine and aRts really won't work properly. Most other parts of KDE do (more or less). If it comes to compilation times - well, I was away most of the time it compiled, so I cannot say much yet ;-) However, I won't put GCC 3 on my workstation until it has shown me that it is able to compile the whole KDE stuff. Seems that we'll have to wait for the next maintenence release of GCC 3 (which will come soon, according to the announcement I got from the gcc-announce list), which will *hopefully* deal with the virtual inheritance bug (and probably some other known bugs as well)." Several others reported the same problem when compiling aRts with GCC3. Workarounds for the new compiler allowed it to build the code, but the resulting aRtsd would segfault on running.

Trill Krech also reported that compile time is considerably slower with the new GCC, while Christophe Prud'homme gave a good run down of some of the issues surrounding using the new, more standards compliant compiler with older code. The GCC team is apparently putting out a maintenance release of GCC3 in short order, so hopefully KDE2 will soon be able to take advantage of the the hard work the compiler people have been putting into GCC in the near future.

6. A KDE CVS Server Is Resurrected

20�Jun�2001 (6 posts) Archive Link: "New CVSup mirror"

Summary By Aaron J. Seigo

Topics: CVS

People: Milo Hyson,�David Faure

Milo Hyson announced the revival of the CyberLife Labs KDE CVS server saying:

few days ago I put the finishing touches on a new CVSup mirror of KDE (see info below). This server was on the mirror list about a year ago and seemed to be quite popular, but was taken offline due to internal company politics. Now that I'm the sole owner of the company, nobody is getting rid of it damnit! :)

The server updates its copy of the repository every night at midnight Pacific time (GMT-7/8). Update status information is available at http://mirrors.cyberlifelabs.com.

And now for the info:

David Faure inquired if it would be possible to make this an anoncvs server as well as a cvsup machine. Milo complied and in short order there was both anoncvs and cvsup services available. It's great to see this resource back online and available for general use. Thanks go to Milo and CyberLife Labs for sponsoring this new server.

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.