KDE Traffic #2 For 16 Mar 2001

By Aaron J. Seigo

Table Of Contents

Introduction

Welcome to KC KDE! Wading through 1000+ messages a week can be a bit much for many who want to keep abreast of the latest KDE developments. For those who do manage to follow the lists, it is nice to have a periodic recap of important threads. In an attempt to address these needs KC KDE provides weekly summaries of the KDE developer mailing lists.

The first issue proved quite popular, being read approximately 5000 times. Hopefully those who read the first issue will find this and future issues of KC KDE just as stimulating and useful.

1. RealPlayer 8 KDE2 Integration

2 Mar 2001 - 8 Mar 2001 (9 posts) Archive Link: "RealPlayer 8"

People: Peter GodmanDavid FaureHetz Ben HamoDaniel Molkentin

If you think that the "Big Boys" aren't watching what is going on in our Open Source world, think again. Peter Godman posted to the kfm-devel list saying:

Hello KFM developers.

Please let me introduce myself: I'm one of the software developers that works on RealPlayer for Unix. I was browsing your archives and saw some discussion about RP and wanted to let you know who I am so that if you have RealPlayer/unix questions or issues, you have a contact at RN.

However, I have an ulterior motive too: I'm trying to write the next generation of browser integration for RP (moving beyond our traditional "mimeinstall.sh" integration) and wanted to ask a couple of questions!

Peter went on to ask a series of questions regarding integration of Real Player into the KDE2 desktop, including such issues as the proper way to make menu entries for new applications, how to find various desktop settings so Real Player can use them without having to ask the user to supply these details yet again and how to have Konqueror recognize and launch Real Player properly.

David Faure, Hetz Ben Hamo and Daniel Molkentin all supplied answers to Peter's questions. Apparently Peter got enough information as he ended the thread by saying, " Thanks very much for all of your help: I'll let you know how it goes: look for integration in the next RealPlayer release!"

2. HTML Form Completion (Ala IE5) in Konqueror

9 Mar 2001 - 10 Mar 2001 (9 posts) Archive Link: "Form Completion"

Topics: Konqueror, Auto Form Completion

People: Malte StarostikDawit AlRichard MooreNikolas Zimmerman

Malte Starostik posted a patch to Konqueror saying, " as suggested by Tackat on IRC I tried myself on form completion as in IE 5 for KHTML. The attached patch does this, seems to work okay, but I'm not sure if I put it into the Right Places (pat. pending). Does it look okay to commit or should it be done in a different place?"

The patch allows Konqueror to supply possible completions to text fields in web forms via a drop down menu, very similar to how it does with URLs in the location bar. Nikolas Zimmermann reported success while Richard Moore, Dawit Alemayehu and Malte discussed some implementation specifics. The patch was eventually given the green light and committed to CVS, giving Konqueror form auto-completion capabilities.

3. (Legacy) X Window Applications on the Desktop

6 Mar 2001 - 7 Mar 2001 (6 posts) Archive Link: "Legacy App Icons"

Topics: Icons

People: Martijn KlingensRik Hemsley

The wealth of high quality X-Window applications that were not written with desktop integration in mind often stick out like sore thumbs when run in a modern X environment such as KDE. In an effort to make these legacy apps blend in better, Martijn Klingens announced: "After some examination of kicker's sources I now have the taskbar working for displaying icons of apps that don't supply their own, based on the task's className."

Martijn was not happy with having only the taskbar properly displaying the icons. However, he was hesitant to patch kwin which handles icons placement in several key places such as the window title bars. He explained his reluctance saying, " looking at kdecore/kwin.cpp, function icon() I can only conclude that I don't understand the code there. No comments and lots of X code of which I literally know nothing at all. Can anybody help me out?"

The next day, not having heard anything, Martijn took the plunge anyways and announced his success patching kwin, saying "I tried to implement this myself into kwin and it _seems_ to work out well. But can someone please review this patch?" Rik Hemsley reported some success but noted that it didn't work properly with rxvt. Martijn said that this was because rxvt didn't have an icon at all and that his patch didn't cover such delinquents yet.

4. audiocd ioslave: Drag 'n Drop CD Ripping in Konqueror

6 Mar 2001 - 8 Mar 2001 (19 posts) Archive Link: "mp3/ogg_vorbis saving in audiocd-io-slave"

Topics: Audio, IOSlave

People: Michael MatzMalte Starostik

As a prime example of what can be accomplished with ioslaves in KDE2, Michael Matz announced: "since some minutes ago the audiocd: io-slave can save the ripped audio files in mp3- (using LAME) or Ogg-Vorbis format (using libvorbis). Kudos go to Carsten Duvenhorst <duvenhorst@duvnet.de>. There are additional top-level dirs "MP3" and "Ogg Vorbis", under them the tracks are listed with extension ".mp3" and ".ogg". When copied from there the destination is automatically compressed by one of the methods. If the CD-info was backed by CDDB also Id3V1 tags are created for the mp3 case, and normal tags for vorbis." The ioslave requires libmp3lame for mp3 encoding and libvorbis for Ogg Vorbis encoding.

Amidst the usual stream of congratulations, feature suggestions and usage questions, Malte Starostik said: " Do you have any other work on this slave pending? Otherwise I'd like to add a little configuration options and an according kcontrol module. What I have in mind is defaults for the cd device and bitrate etc. as well as a possibility to change the track naming formats." Michael suggested Malte coordinate his efforts with Carsten who was already designing a kcontrol module for the audiocd ioslave. Currently all options, such as encoding bitrate, are passed to the ioslave via additional arguments to the audiocd:/ URL.

5. Mixing International Character Encodings

7 Mar 2001 (9 posts) Archive Link: "Mixing encodings with an HTML page"

Topics: i18n

People: Eric BrunetLars KnollDirk Mueller

Good internationalization support is not a trivial task. Eric Brunet pointed that Konqueror can not display different character encodings within the same document. After posting an example page that mixed several different international character sets, he explained Konqueror's current behavior saying:

This is I believe a perfectly valid html file, but as far as I can tell, there is no way to have konqueror display it properly. There should be three lines, an uppercase omega (greek), a small e with acute (western europe) and an uppercase de (russian). If I let the encoding to auto in konqueror, the omega is correct and I have then two question marks. If I choose a latin-1 encoding, then I have the small e with acute, but the omega looks like a capital u with grave and the de like a question mark. Finally, if I choose an utf-8 encoding, then both the small e with acute and the capital de are correct, but the omega is not there. (And it is even worse than that: while trying to interpret the 0xd7 as a multi-byte sequence, the parser ``ate'' the <, and the result looks like [weird character]p>é...)

So it looks that konqueror is not able to display a page by using characters from different fonts with different encodings.

Is there any chance that in a near future, the best browser in the world would be able to handle such pages ?

Lars Knoll answered, saying: "Unfortunately, the X11 font concept makes this exceedingly difficult to implement. There are a few ways to get this working... The real solution will however only come with Qt-3 where we get a real good abstraction of a font, that hides all the uglyness (8bit'ness) of the X11 font model." Eric expressed his doubt that it would be so easy, saying: "A good abstraction of fonts within X11 is like a holy grail... But I trust TrollTech: if it is possible, they will do it." To which Lars replied: "Have a look at my mail address... ;-)" Of course, Lars works for Troll Tech and is therefore intimately familiar with the new QFont capabilities in Qt3.

Elsewhere Dirk Mueller asked if it would be possible to backport QFont to Qt 2.x for khtml. Lars replied that this was not possible due to the number of classes internal to Qt3 that QFont relies on. We will just have to wait for Qt3 to be released.

6. How to Write an ioslave For KDE2

7 Mar 2001 - 8 Mar 2001 (7 posts) Archive Link: "ioslaves"

Topics: HowTo, IOSlave

People: Michael JarrettDavid Faure

Michael Jarrett asked: "I could be blind, but is there a decent document anywhere on how to write a basic ioslave? Or do you just have to more or less discern it by reading the code for the slave base classes?" . Heiko Nardmann pointed Michael to an online book for KDE2 development (http://andamooka.org/kde20devel/) . David Faure semi-jokingly pointed out that reading the code works as well.

7. KDE Library Dependencies on Qt's UIC

7 Mar 2001 - 8 Mar 2001 (22 posts) Archive Link: "fun with uic"

People: Matthias ElterStephan KulowCristian TibirnaMichael GoffioulLars Knoll

Stephan Kulow was the first to note that the new kdeprint library (covered in Issue #1, Section #1  (28 Feb 2001: New KDE printing system) ) required Qt's UIC program to compile. UIC translates XML files generated by Qt Designer into compilable C++ GUI code and is used for creating dialogs and other GUI components. Stephan noted that this dependency within kdelibs was a bad thing.

Matthias Elter explained the problem saying: " In fact it is a very bad idea. kdelibs should not require uic because of circular dependencies with the designer." Lars Knoll replied saying that he wasn't aware that UIC depended on KDE. However, Stephan pointed out that UIC can indeed link with KDE and gave the solution, saying: " we don't say you should not use uic to create the files, just that you should not use them to compile CVS kdelibs. You can put the result into CVS."

Michael Goffioul was quick to point out, however, that UIC is dependant on the version of Qt it ships with and may break between versions, making it a bad idea to not rely on UIC to generate the source files at compile time. Cristian Tibirna countered with " The solution is simple... KDE at a given moment relies on the given qt-copy. UIC of a given qt doesn't change over time. Thus, regenerating the sources... each time we change qt should suffice."

8. Digital Certificates and kmdcodec

7 Mar 2001 - 9 Mar 2001 (28 posts) Archive Link: "base64 codec required before KIO"

Topics: Security

People: George StaikosDawit AlemayehuDawit Al

While extending the capabilities of KDE to handle X509 digital signature certificates, George Staikos said: " I think I'm going to need the base64 codec in libkssl to store seen X509 objects in KConfig. (yes it's a pain but it's the best solution I've been able to find) Basically I have a triple (CN, Policy, X509) that will be stored for each site which has a policy declared (Always accept, never accept, etc). The X509 certificate is an array of unsigned char and may contain \0 so I can't just convert it to a QString. I didn't' find any method in KConfig docs for storing binary data so I assume that I'll have to use a base64 encoding. Should I just copy the base64 code from KIO into the .cc file that needs it? (it's only internal to one class) Anyone have a better solution?" George also noted that this code will eventually be extended to manage personal certificates, enabling KDE to work seamlessly within a public key infrastructure (PKI).

Dawit Alemayehu said that copying the needed base64 code from KIO would defeat the point of the kmdcodec classes, which he wrote to avoid duplication of code. Dawit gave his recommendation saying: "My suggestion here is to do what I wanted to do initially and move the kmdcodec stuff into kdecore and make it build a standalone library (libkmdcodec)." This sparked a long thread involving various developers debating whether kmdcodec was really necessary, whether it should be made into its own library or simply added to kdecore itself right away. In the end concensus was that it should be moved directly into kdecore.

9. New Scanner Library and GUI

9 Mar 2001 (12 posts) Archive Link: "kdelibs/kscan + kdegraphics/kooka + koffice/plugins"

Topics: Multimedia

People: Nikolas ZimmermannNikolas Zimmerman

Nikolas Zimmermann announced the readiness of a new scanner interface for KDE, stating:

1. KScan: i would like to move our new "KDE2 Scanning Library", written by Klaas Freitag <freitag@suse.de>, to kdelibs/kscan (good idea?)

It's working great! You can find it under kdenonbeta/kscan at the moment. I only checked the built under Linux, don't know about other Unices..etc... can someone check?

2. Kooka: Kooka is the "frontend" to kscan, it's a very nice scanning program with tons of possiblities what do to....MassScan, OCR....and much more. I think kdegraphics is the right place for it.

3. KOffice: I wanna add the directory koffice/plugins, where we can place KParts::Plugins in future to provide plugins for all koffice applications. For example: I'm going to write a scan plugin, if kscan is in kdelibs, which adds scanning support to all koffice apps, which support "Insert image" (This will be done by extending kofficelib..etc... as discussed with david)

Previously KScan and Kooka were housed in the kdenonbeta CVS module. Now that they have matured to the point where they are usable and stable, they have both been migrated to the kdegraphics CVS module and made part of the official KDE2 set of applications. The KOffice plugin will also allow those with scanners to access them directly from KOffice applications.

10. KDE Usability Study

8 Mar 2001 - 9 Mar 2001 (4 posts) Archive Link: "KDE Usability Study (was Re: User Interface guide)"

Topics: KDE Usability Project

People: Jonathan Bacon

Jonathan Bacon posted to the devel mailing list, saying:

I just thought I would let everyone know that myself and Lee Jordan are in the process of building a KDE Usability Study to test for many of the UI interface flaws that we may not realize.

Lee is currently maintaining a website for the study while I am getting the KDE booth at the UK Linux Expo ready. We are going to conduct the research at the Expo, and should have some usable figures after.

We are just getting the test conditions and test questions ready at the moment, and anyone who is interested in contributing should get in touch.

KDE Usability Study Site: http://www.wlv.ac.uk/~f9913820/kde/ (http://www.wlv.ac.uk/~f9913820/kde/)
UK KDE Linux Expo Booth site: http://www.wlv.ac.uk/~f9808590/ (http://www.wlv.ac.uk/~f9808590/)

Data on real-world usage of KDE by experts and neophytes alike could go a long ways to highlighting the areas where KDE2 needs refinement. Both Jelmer Feenstra and Paul Campbell suggested using video cameras and live hands-on testing to get even more data on the usage patterns of new KDE2 users.

11. IPv6 in KDE2

12 Mar 2001 (4 posts) Archive Link: "IPv6 -- we're almost there"

People: Thiago Macieira

Thiago Macieira wrote: "Having received no more bug reports on the current support for IPv6 in KDE, I'm tempted to bring it to the next level: commit it." This new KDE2 IPv6 support has been tested on Linux, AIX, Tru64 4.x and Solaris 2.6 and 7. It is also expected to work on Solaris 8, Tru64 5.x and the BSDs.

12. SDI vs MDI vs Both

12 Mar 2001 (9 posts) Archive Link: "Duplicated efforts and consistency (SDI/MDI in konq, konsole etc. ...)"

Topics: UI

People: Torsten RahnMartijn KlingensWaldo BastianCullmann Christoph

Torsten Rahn resurrected the SDI (Single Document Interface) vs. MDI (Multiple Document Interface) debate this week. KDE2 supposedly prefers SDI. However Torsten listed several KDE2 applications that were either MDI or had MDI traits and then concluded " sooner or later all of the apps above and in the future a lot of apps in addition (like kspread, kword etc.) will offer *all* kinds of MDI for sure anyways. Unfortunately there is already quite some diversity in the way MDI-apps look&feel (tabbed mdi in konsole compared to kspread/ksirc e.g.)." Torsten expressed his concern that this duplication of effort was making KDE " a less-consistent desktop as well as a less-rapidly-evolving-desktop than it could be."

Martijn Klingens agreed saying "I personally use MDI and SDI in Konq at the same time often. Like you say, it really depends on what you're doing." Martijn went on to suggest: "If we can come up with a generic class that lets you switch views from SDI to MDI and vice versa it would give everyone what he/she needs at a given time. I've always found a fixed MDI/SDI too restrictive and I would really like a way to combine both in an app."

Waldo Bastian added that toplevel MDI, as often seen in MS Windows, is fundamentally broken. Waldo did note the benefits of tabbed and Emacs-like MDIs, adding this caution: "With a more general MDI solution, applications should default to SDI with an configration option to enable MDI mode. That way the application can dump a bunch of its menu-entries when running SDI, making it less heavy handed and overwhelming for new users."

Other developers, including Torsten Rahn and Cullmann Christoph, expressed support for this flexible approach. The thread petered out at this point. It will be interesting to see if such mixed SDI/MDI functionality makes its way into KDE.

13. New KDE Games Mailing List

12 Mar 2001 - 11 Mar 2001 (1 post) Archive Link: "Mailing list for KDE games"

Topics: New EMail List, KDE-Games

People: Joseph Spillner

Joseph Spillner announced a new KDE development mailing list for games, 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.

Those following KDE2 progress in CVS will have noticed a lot of activity over the last several weeks in the kdegames module, including the ongoing development of a generic game library. Best of luck to those aiming to bring a little recreational material to our desktops!

14. kISDN Authors to Donate ISDN Dial-up Functionality to KDE2

13 Mar 2001 (4 posts) Archive Link: "kISDN"

Topics: New Application

People: Thorsten WestheiderFrerich Raabe

The KDE modem utility kppp is extremely popular among those on Linux with dial-up access to the Internet. With regards to extending kppp beyond just modems, Thorsten Westheider said: "I'm one of the authors of the commercial application kISDN and I consider releasing parts of the sources under a GPL licensing for the purpose of adding native ISDN dialup functionality to the KDE. Q: If I were to do that, would there be people interested in integrating that stuff in the KDE? "

Frerich Raabe wanted to know if Thorsten was proposing this as a full replacement for kppp. Thorsten clarified his proposal saying, "I think it'd be better to have a common PPP layer that way that PPP connections of any flavor (PPP over modem, PPP over ISDN, PPP over Ethernet etc.) could be handled the same way, no matter what kind of link PPP is run over. That PPP layer would be responsible for opening/closing a PPP connection, giving status information etc. Code taken from kISDN could then be used for building the ISDN layer in this model."

If this integration occurs it would be a profound extension to the existing PPP support within KDE.

 

 

 

 

 

 

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.