KDE Traffic #3 For 23 Mar 2001

By Aaron J. Seigo

Table Of Contents

Introduction

Welcome to KC KDE! As the tireless KDE hackers continue to amaze and impress their user base with the KDE2 development series, the entire project is branching out ever further to cover more ground. Reflecting this, it was another full week on the mailing lists with two new lists announced: kde-games and kde-usability. Look for coverage of these new lists in future editions of KC KDE. Also of note was the establishment of KDE Women (http://women.kde.org) to provide support and help to the female population of KDE users and developers.

I hope you enjoy this issue as much as I did preparing it and, as always, happy hacking!

1. Mailing list for KDE games

12 Mar 2001 (5 posts) Subject: "Mailing list for KDE games"

Topics: New EMail List, KDE-Games

People: Josef Spillner

What is a desktop without some games to play? Not much fun at all! To help coordinate those working on bringing more fun to the KDE2 desktop, Josef Spillner announced a new mailing list specifically for game development, saying: " Just for those who haven't taken a look at games.kde.org recently, there is now a separate mailing list which targets the development of KDE games: kde-games-devel@master.kde.org. Anything from weird wishlist items to important bug fixes can be brought on that list. People with graphics skills and interest in games development are especially welcome there." There has already been a fair amount of traffic on the list, mostly regarding the new KDE game library that is being written.

2. Goodbye Kwrite, Hello Kant?

12 Mar 2001 - 14 Mar 2001 (59 posts) Subject: "Can we drop KWrite ?"

Topics: KWrite, Kate

People: Cullmann ChristophRik HemsleyBernd GehrmannSimon HasumanDavid FaureFalk BrettschneiderSimon HausmannMartijn Klingens

KWrite has been a part of KDE for a long time as a simple yet useful programmer's editor. It survived the 1.x to 2.x developments and evolved a lot along the way. However it is said that all good things must come to an end and in this case it was Cullmann Christoph who got the ball rolling saying, " I have just created a Kant Part, which has the same features as the old kwrite part ! Now the only reason for having the old kwrite stuff in kant, the kwrite part, is away. Is there any problem to drop the KWrite stuff ?" The Kant project is attempting to develop a simple yet powerful code editing environment that includes aspects of MDI, project management and even an integrated console. CVS activity around Kant shows an amazing amount of effort going into this program.

Faced with the removal of KWrite, some started making feature requests and asking for more details on Kant's capabilities. Falk Brettschneider wanted to know if multiple views of the same document were supported, while Martijn Klingens asked if syntax highlighting was configurable. Cullman gave affirmative answers to both off list.

Rik Hemsley posted a less than supportive reply saying, " I thought we were anti-MDI, but it seems that kant appeared in kdebase while I (and presumably the kde-look people) weren't looking. Why should kwrite be dropped ? Are you its maintainer ?" This kicked off a very long series of threads debating document centric versus application centric interfaces with people arguing passionately on both sides.

Ralph Nolden posted saying that KDE doesn't have a true document interface and that this was the real problem. Simon Hausmann corrected Ralph pointing out that KParts was exactly what Ralph was looking for. In counterpoint, Bernd Gehrmann said: " Except that kparts (more precisely, PartManager) doesn't support multiple views of a document as childs of the same toplevel window, because the part activation is based on Part::widget(), which does not exist in the case of multiple views per document." Simon replied that multiple views are indeed possible if the developer extends the KParts interface. Noting that this is not an ideal situation Simon went on to say, "We might want to provide a class in KParts which one can use out-of-the-box for multiple views, as reimplementing hitTest is not something really convenient." Some implementation discussion occurred at this point between Simon, Bernd, and David Faure regarding how to accomplish this.

It was also agreed by the end of the thread that KWrite would remain in name so as to not create inconsistencies between minor versions of the desktop. As Cullman pointed out in a later post, Kant can be made to look and act exactly like KWrite does by disabling its advanced.

3. Palm Pilot IOSlaves

13 Mar 2001 - 14 Mar 2001 (11 posts) Subject: "What about kpilot_ioslave ?"

Topics: IOSlave

People: Michael SeiwertAdriaan de GrootDan Pilone

Michael Seiwert proposed the creation of a Palm Pilot IOSlave. He explained his thoughts further, saying: " You put something like '#topofpage' in your url and the Pilot starts to hot sync your Pilot. Another nice thing is to design a html input form inside the Konqui which allows you to add Adresses, dates, todo's and many more."

Adriaan de Groot was quick to point out a problem with this idea, explaining:

The Palm Pilot requires external action to start communication. It's *NOT* a device that you can just send bytes to and expect an answer. You have to either:

a) Have an app running on the Palm that expects serial input or
b) Have to push the hot-sync button to get the Palm to start sending bytes

neither of which is really conducive to an ioslave kind of setup.

Adriaan also noted that writing such an IOSlave would be duplicating some of the work already done by the KPilot (http://www.slac.com/pilone/kpilot_home/) project.

Dan Pilone was quick to agree with Adriaan, but he did see some possible uses for a Palm IOSlave saying, "what _might_ make sense would be something along the lines of palm://addresses or palm://todo and that would give you a pretty HTML rendering of your addresses or Todo's or something like that." Joerg Menke replied that he had already started on such an IOSlave just a few days earlier. Joerg, Micahel and Dan decided to team up and took up the ensuing design conversation off-list.

4. Persistent Data Storage In KDE2

14 Mar 2001 - 18 Mar 2001 (12 posts) Subject: "storing information with kde."

Topics: KConfig

People: PupenoDirk MuellerShawn GordonRoberto Alsina

Pupeno asked: " Does KDE provides any way to store information (some kind of small database) to use in my kde application, I want it to be stored in the default kde application directory (whin usually is ~/.kde/share/app/appname ). I know that KFile provides some ways to get the standard directories, but I don't want to make a plain database, I need something more sofisticated, as KDE Address Book have. What can I use ?"

Dirk Mueller outline his options as being one of KConfig, KAB or kdedb. After looking over these options, Pupeno said: "kab and kconfig aren't what I need, they're not versatile databases and kdedb just work with mysql, I don't want to tell the people that they need a sql server to use my simple application, is there any other posiblity, I just want to make something like an address book..." . Pupeno also asked if kdedb was going to be a standard part of KDE 2.1. Dirk replied that yes, indeed, kdedb was to be part of the 2.1 release. It is also worthwhile to note that kdedb plugins for PostgreSQL and Informix have been added to CVS.

Roberto Alsina suggested that Pupeno look into Gigabase or SQLite, while Shawn Gordon noted that theKompany will be releasing Rekall shortly which has an xBase default file format.

5. KDE Socks Support

15 Mar 2001 - 20 Mar 2001 (13 posts) Subject: "KSocks on non-linux systems."

Topics: Sockets, Operating Systems

People: George StaikosRob NapierWaldo Bastian

In what is another large step forward for KDE interoperability, George Staikos announced the addition of Socks support, saying:

Here's SOCKS support for KDE. This is a generic utility which reimplements a bunch of LIBC calls. It can auto-detect the version of SOCKS installed and will have a configuration panel in the near future. Right now it works with Dante and NEC SOCKS. Note that it does not in any way link to these at compile time. You don't need headers or libraries installed. Everything is done at runtime.

Please: anyone on non-linux/glibc2 platforms could you check this code and see what needs to be done to make it compile for you? I am sure that there will be subtle libc and #include differences that need to be addressed.

As of right now, this code is not in the build. Once we have it compiling in at least Linux, FreeBSD and Solaris I will commit it. Then it needs to be integrated into KSocket, TCPSlaveBase, and any other apps that wish to use it.

Rob Napier reported that it wouldn't build on Solaris. He supplied a patch, then retracted it calling it crude and posted a better one asking for others to review it. Waldo Bastian gave a few pointers, at which point Rob announced success saying, "Since George is out sick with work :) could someone apply this patch? I've changed it as per Waldo's suggestion." Socks support should now build on all Nixes supported by KDE2.

6. KXMLRPCD and KDESUD Security Concerns

16 Mar 2001 - 17 Mar 2001 (5 posts) Subject: "Mysterious kdesud network connection"

Topics: Security

People: Christoph BartoschekKurt GranrothDawit AlemayhuDawit AlWaldo Bastian

After starting up KDE 2.1 and running nmap, Christoph Bartoschek saw what he considered to be some odd behavior. He posted his findings to the list, saying: " The nameserver, pop3, smtp and nntp servers listen on the loopback device, but there is kdeinit: kxmlrpcd listening on all devices. I consider this is a security hole. How can I force this deamon to listen only on loopback? How can I prevent it from starting?"

Kurt Granroth, the KXMLRPCD author replied saying, " I am looking into why kxmlrpcd is always taking 1024 instead of a random port like it's supposed to. kxmlrpcd is INDEED supposed to listen to a TCP port. It's a useless program if it doesn't. The fact that it uses a TCP port makes it a *factor* in any security sweep... but it certainly doesn't make it a problem." Christoph then asked how to turn it off completely and Waldo Bastian gave him instructions on doing so.

But that wasn't Christoph's only concern. Concerning his nmap output, he wrote: "I am wondering about the line with kdesud. Why is there a network connection from this program? Sniffing the network with ethereal I can see, that the very first http request is conducted through this network connection. Why does not konqueror do this? Why is the connection held in CLOSE_WAIT until I terminate the kdesud process? I do not like the situation that there is a connection to kdesud, even if it is in state CLOSE_WAIT. Maybe a security hole?"

Dawit Alemayhu explained the reason for the open port saying, "The kdesu daemon is used to cache password when you connect to password protected sites. Whenever you use http, for every connection the http io-slave tries to look-up if there is a stored password for that site. Anyways, the problem came about because of a forking issue which has been fixed in CVS and for 2.1.1 release. I do not think this is a security hole since it simply means that the connection is kept, much the same way as a persistent connection would, to that specific remote site."

7. Forte For Java Problems

18 Mar 2001 - 19 Mar 2001 (4 posts) Subject: "Forte4J incompatibility"

Topics: Java, UI

People: Derek FountainMichael AndreasenMatthias Etrich

Derek Fountain twice reported problems with Sun's Forte For Java on KDE2, saying: "The Sun "Forte for Java" IDE doesn't work too happily with KDE-2.1. Forte4J uses several windows open at once as a "workspace" - e.g. the 'editing' workspace might have the editor window, the class browser, and whatever other windows you choose to have open. The main problem is when you switch virtual desktops. When you switch back, all the windows for your workspace are closed, except one. If you want the others back, you have to go and open them up again. Making the windows sticky doesn't help." Avi Schwartz clarified that the problem isn't that the windows get closed, but become minimized. There was no forthcoming solution during this thread.

Michael Andreasen was the next to complain a few days later, saying "How can KDE be made to NOT control the size and placement of created windows. I am noticing this mostly in java programs which open losts of windows, that need to be opened at exact positions on the screen. Forte4Java is unusable with KDE as another poster has pointed out." He noted that while Forte works just fine in KDE1, IceWM and MS Windows it fails miserably in KDE2. Michael suggested it was KDE2's automatic window placement algorithms.

Finally, both Matthias Etrich and Stefan Hellwig stepped up with the answer. Matthias gave the solutions, saying " I just tried your program and it works fine. What jvm are you using? Seems like some older jvm's were relying on some ancient obsolete fields in the XSizeHint structure. Modern WMs dropped support for that, as it breaks some modern applications." Stefan noted that the Blackdown JDK 1.3 works just fine.

8. Standard DCOP Service Definitions

18 Mar 2001 - 19 Mar 2001 (6 posts) Subject: "Registering DCOP "services" instead of just programs"

Topics: DCOP

People: Guillaume LaurentWaldo BastianRik Hemsley

While working on email client and address book integration in KDE2, Guillaume Laurent realized that he was duplicating his efforts several times over. Therefore, he wrote to the list saying: "It seems to me that we could benefit from a set of standard DCOP interfaces (e.g. "services") which some programs filling a well-defined purpose would implement. For instance kmail would implement a "Mailer" service (which Aethera and any KDE mailer would implement as well), abbrowser and kab would implement an "AddressBook" service, etc..."

What this would mean is that any application that implements a given DCOP Service could be replaced with any other program that implements the same DCOP Service without any loss in integration. It would allow different users to choose different applications based on personal preference and still have the desktop operate exactly the same.

Rik Hemsley replied that he was already working on implementing this concept. Waldo Bastian also pointed to the KTextEditor, KParts and ServiceType features already in KDE2. Through the efforts of these and others, allowing individual programs to be plugged into (and out of) the desktop dynamically is already possible and being extended even further.

9. Font Selection Widget With Font Previews

19 Mar 2001 (12 posts) Subject: "KFontCombo for kdeui?"

Topics: UI, Fonts

People: Malte StarostikDavid FaureMartijn Klingens

Scratching an itch, Malte Starostik wrote to the list: "annoyed by the font-selection comboboxes which do not give a hint about how fonts look, I wrote KFontCombo which paints the font names in the popup list in the corresponding font itself. It also has methods to set the fonts to bold, italics etc. The sources and a screenshot are available from http://malte.homeip.net/kfontcombo/"

Simon Hausman, Martijn Klingens and David Faure all liked the concept but were concerened about performance issues related to loading and rendering all the fonts. David also said, "most KDE apps use - or should use - KFontAction. Why not improve KFontAction itself (which presents a combo when being plugged in a toolbar) ? Then the apps would gain from the change automatically." Pooling all the constructive criticism, Malte came back saying, " Looks like all replies demanded for demand loading... the sources are updated now to do this. Saves quite a few seconds on creation of the combo box. I'd also go for a global option to disable it completely and use the default font instead."

10. KDE2 Dependencies and Packaging Considerations

20 Mar 2001 (5 posts) Subject: "Things that go BUMP in the release"

Topics: Packaging KDE, KDE 2.1

People: David FaureJames TappinAdriaan de Groot

Adriaan de Groot reported that KPilot 4.0.0 was ready for inclusion in the 2.1 release. David Faure confirmed that KPilot was indeed in kdepim for 2.1, but noted, " kpilot might not get compiled on some distros because it depends on libpisock and only gets compiled if libpisock is available. I'm forwarding the packagers so that they check that they have libpisock before building the packages for kdepim. Note that another new dependency since 2.0 is libpcre for the javascript regexp support (www.pcre.org)."

This adds to a growing list of dependencies KDE2 has on third party libraries for certain non-core applications to be built. Other dependencies include libsmb for the SMB KIOSlave (covered in Issue #1, Section #2  (6 Mar 2001: kio_smb and libsmbclient) ) and cdparanoia, libmp3lame and libvorbis for the audiocd IOSlave.

Bernhard Rosenkraenzer suggested putting libpcre into kdesupport. David Faure reminded him that kdesupport was not being added to. In fact, there is an ongoing attempt to phase out kdesupport altogether. David cited that the reason for this is the inevitable library version conflicts that occur on the various operating systems KDE is packaged for when kdesupport is relied upon.

James Tappin noted the obvious solution to the problem, saying: " it might be a good idea if kpilot were packaged as a separate package (depending on the rest of PIM if necessary). For 2.1 on RH6.2, I had to install --nodeps (I have no wish to install libpisock as no-one here has a Pilot). While that's technically no problem it's not nice to leave dead menu items/non-functional programs around. I know that in the end it's the packagers' call, but that's a not-too-subtle hint." Such separate packaging is probably a good idea for most if not all of the parts of KDE2 with external dependencies.

Packagers: are you listening?

 

 

 

 

 

 

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.