KDE Traffic #10 For 17�May�2001

By Aaron J. Seigo

Table Of Contents

Introduction

Welcome to KC KDE!

1. Busy Cursor While Applications Load

8�May�2001�-�9�May�2001 (38 posts) Archive Link: "kdesktop wait cursor"

Topics: UI

People: Ralf Nolden,�Torsten Rahn,�Lubos Lunak

Ralf Nolden gets to see KDE in real-world use by providing it on the machines that the customers use in his cyber-cafe. This gives him a good perspective from which to suggest changes based on actual usage. Ralf made one such suggestion this week saying, " the users are *not* capable of understanding that starting applications may take some time. The result is that they click on the konqueror or netscape icon 5 or more times which slows down the machines (diskless clients) even more. So what is needed besides the taskbar start notification is to also set the cursor to wait cursor. A new hourglass cursor with a pointer a la windoze would be the best option, this one can be black and white so this shouldn't be a problem to do actually. But changing the cursor is *very* crucial."

Torsten Rahn agreed with Ralf's idea saying, "Most users don't notice the tiny little animation on the taskbar (unless someone tells them or they see it by accident). This is a big advantage of the "busycursor"-solution. Most users who start an application _do_not_ look at the taskbar. They focus by far most of the time on the mouse-pointer, because that's the location where they can manipulate the desktop. Therefore changing the mousecursor while pointing it over a busy application is the best solution I can think of currently."

Lubos Lunak offered his opinion saying, " This is going to be a little problem, since AFAIK all widgets may specify their cursor and it can't be globally overriden. And I don't think that changing the cursor is the only and best way of doing it. It can be easily made that you get a little splashscreen for every app as a startup notification, or you can even write an app that will do 'beep beep' everytime you start Konqy or Netscape." Torsten noted that it must be possible since Gnome has a busy cursor. Several others also added that many users dislike splash screens and that noises are not a good solution where several computers are in close proximity, such as in a cyber cafe or office. Lubos later clarified that he was just giving examples of how one could provide the user with notice of application start-up in many different ways in order to demonstrate the flexibility available. Lubos also figured out how to create the busy cursor saying, " It's easy, they must be simply creating a new borderless window containing only a look-like-busycursor pixmap. But as I said, this changes the cursor for everything." Other options were discussed but in the end it was decided that the busy cursor is indeed the best option. Some code appeared in CVS shortly thereafter providing a launch notification animation alongside the mouse cursor.

2. Help Wanted: KWin Maintenance

9�May�2001 (5 posts) Archive Link: "Need help with kwin maintainance"

Topics: Bug Tracking

People: Matthias Ettrich,�Christoph Cullman,�John Firebaugh

SEE ALSO: same thread in devel

Matthias Ettrich announced on the core-devel list: " I need help with kwin maintainance. I would like to donate some time before 2.2 to fix the most severe outstanding bugs, but looking at the buglist (http://bugs.kde.org//db/pa/lkwin.html) is not really encouraging. Many of the things here are already fixed, some are not reproducable. The problem with the list is, that it is real work to close all those bugs (there's no checkbox and there's no way to close several with one mail and still give a short specialiued comment to every submitter)... KWin is a fairly important KDE desktop component. I can still maintain it in a sense that I can look into and fix issues with it. But maintaining the bug list is too much for me right now. So if there is anybody or even better: a few people out there who would like to help, that'll be great."

This prompted both Christoph Cullman and John Firebaugh into action (and assumedly others as well) into a flurry of bug report checking, closing and reassigning.

3. Headers for Konqueror Parts and a DOM Tree Viewer

9�May�2001�-�10�May�2001 (7 posts) Archive Link: "konq_frame header"

Topics: KParts, Konqueror

People: Mark Deneen,�Andreas Schlapbach

In the "cool hack but also nice for usability" department Mark Deneen said, "I've added a header to all konq frames which are toggleable. It is a simple class which just has a label and a button. The label is the title of the header, and the button will toggle the part. (closing it) I have a screenshot up at http://tick.dhs.org/~deneen/kpart-header.png." It was welcomed with open arms and there was discussion had as to how it could be made even better.

In the same thread Andreas Schlapbach announced a GUI DOM tree viewer for use by the khtml developers saying, " I've got tired of staring at stdout so I've written a DOMTreeView-Plugin. I hope to make it usable for all you kfm-developers so please give me feedback how I can facilitate your work with it. (Initial version in CVS)"

4. House Cleaning in kdeutils

9�May�2001�-�10�May�2001 (24 posts) Archive Link: "kdeutils cleanup"

Topics: Printing

People: Matthias Elter,�Michael Goffioul,�Torsten Rahn,�Neil Stevens

Matthias Elter requested comments on some house cleaning in kdeutils saying, "I would like to clean up kdeutils for the 2.2 release a bit. Both klpq and kljettool are unmaintained and obsoleted by the new print framework. I propose to move both to kdenonbeta or better /dev/null. ktimemon is not required any more now that ksysguard has decent panel applet support. It should disapear, too. kpm should die. We have ksysguard in the base distribution which is maintained." Several people objected to the removal of KPM as they still use it and prefer it over KSysguard. Torsten Rahn noted that at one point KPM was did not display correctly with certain color schemes, but Neil Stevens reported that this bug was fixed in CVS. Due to popular demand KPM will still be with us.

As for kljettool and klpq there was not reply, prompting Matthias Elter to say, " So no comments on the proposal to remove klpq and kljettool which are obsoleted by the new printer framework. David, kann you move both to kdenonbeta please?" However Michael Goffioul, the KDE printing system's author, replied, " klpq provides print job management, which is still not implemented in kdeprint. I don't know very well kljettool, but it probably also provides some features which are not present in kdeprint. So it is maybe wiser to keep them available. On the other hand, if anybody is interested in implementing those features, it would be welcome. I can't do everything, unfortunately." So it seems that these two tools also have a new, if temporary, lease on life.

5. New KSpread Filter: Quatrtro Pro

9�May�2001�-�12�May�2001 (4 posts) Archive Link: "[Fwd: Quattro Pro filter for kspread]"

Topics: KOffice, KSpread, Filters

People: David Faure,�Werner Trobin

Earlier this year Graham mentioned on the koffice-devel list (http://lists.kde.org/?l=koffice-devel&m=98442608612490&w=2) that he was interested in providing a Quattro Pro filter for KSpread. He came through on this promise and Werner Trobin was going to commit the results but had some questions as to how and where it should be committed. David Faure answered saying, " From the sourceforge page, it seems that the library is by the same author, Graham. The library is simply a reuseable part of the filter (for other office suites). So I think the whole thing should go in CVS, the filter and the lib for it. Otherwise the filter is useless :) The only problem will be keeping the two repositories in sync, as usual. Graham: I can provide a CVS account for the KDE CVS, of course. Simply send me full name + email + encrypted password (md5)." A short time later Graham replied that his CVS account was working well and he was checking in the filter.

6. SSL for KIOSlaves

10�May�2001�-�11�May�2001 (5 posts) Archive Link: "SSL on KDE protocols (ioslave developers please read this)"

Topics: Security, KIO

People: George Staikos

George Staikos has been working on being able to load openSSL on demand for ioslaves. He announced initial success saying,

Tonight I added SSL support to TCPSlaveBase and extended this into kio_smtp, kio_pop3 and kio_imap. I also added TLS (via STARTTLS/STLS) support to TCPSlaveBase and thus far have extended it to kio_smtp and kio_pop3. This code isn't complete yet, but it's good enough for a start. I have added the hooks into kcmcrypto and kmail for this so far. (although KMail still doesn't use kio_smtp)

This code does not yet verify certificates. This will come later (probably after the beta, _possibly_ before). Any application which wishes to verify these certificates will have to communicate with the slave via metadata and link to KSSL to get the X509 dialog. I can provide info on how to do this later (over the next 2 months).

[ Note: certificate verification isn't actually complete in kio_https either. There is still some code missing because it's very complicated, especially with HTML, and it takes time to do this.]

Another flaw is that TLS is a little too transparent right now. It should be providing feedback to the app if TLS is requested and isn't available or fails. Right now if TLS is enabled in kcmcrypto (default) and the server claims to support it but negotiation fails, the entire slave session will fail. This should be rare, but it _can_ happen.

Additionally, I am slowly but surely working on a certificate manager and generator. It's a lot of work. When I finish it, we will be able to send client certificates out (on _all_ slaves, managed from the same manager). I also hope to provide X509 authentication with this. (probably the best auth scheme you can get)

George then asked for users to test and for the maintainers of ioslaves that need some work before they can take advantage of the new SSL capabilities to supply the required patches. Work continues to "get it right" across the board, but in the end we will have a desktop that is not only network aware but one that can encrypt most if not all of its network activity.

7. Default Address Book Front End Chosen

11�May�2001�-�12�May�2001 (12 posts) Archive Link: "Default KDE address"

Topics: KDE PIM, KMail

People: Matthias Elter

KDE2 has a single address book for contacts, but several front-ends to it that vary in flexibility and power. "Addressing" this issue, Matthias Elter said, " I think it is time to agree on a default address book frontend for KDE. We got bad reviews from journalists (see recent c't article on KMail) that are not able to find our modern address book frontends. Only a small percentage of our users seem to know that modern address book frontends for KDE exist... The problem is that many users don't know about this setting hidden deep in the KMail configuration dialog. Even journalists fail to notice it with the consequence of bad reviews because of the default "Traditional KMail" address book interface. IMHO it is embarrasing to ship KMail with "Traditional KMail" enabled as default address book frontend. I propose to:

"

With agreement all around and no opinions to the contrary to be heard, abbrowser was given a new name, moved to kdebase/kaddressbook and christenned the default address book front end for KDE2.

8. Xinerama Support for KSplash and KWin

11�May�2001�-�14�May�2001 (4 posts) Archive Link: "Preliminary xinerama"

People: Balaji Ramani,�Dirk Mueller

Those KDE'ers fortunate enough to have a dual head display will be happy to hear that Xinerama support has been added to KSplash and KWin. Balaji Ramani announced this saying,

I have added xinerama support to ksplash and kwin. With this, ksplash displays in the center of screen 0 (rather than being split between the two screens). The patch is against CVS as on May 11, 2001. The patch can be found at http://www.yablibli.com/~balaji/xinerama.patch

For kwin, the change is very small, but the effect is quite unexpected (!).

  1. With smart placement turned on, windows open on the physical screen that the mouse is.
  2. When you maximize the window, it gets maximized only to the size of the physical screen.
  3. When you move a window from one physical screen to the other, you feel resistance on the border of the two screens.

I further plan to add options to make these configurable options through kcontrol.

Dirk Mueller responded with two questions about the patch saying:

Regarding the first point Balaji mentioned he was having trouble building the programs without linking to Xinerama (which Dirk fixed later). As to the second point Balaji said, "Yes. It should be possible. As I mentioned, once I implement enabling the options through kcontrol, I will make it a flag. I am sure that a lot more has to be done for full Xinerama support. I just did this a quick and dirty hack for kwin. I could not stand windows opening up over the middle of the screen and being spread across two physical screens. So, I implemented this just for kwin. I shall add the kcontrol option when I get some time."

9. New Console App Menu

14�May�2001 (4 posts) Archive Link: "Another applnk proposal"

Topics: Konsole

People: Rob Kaper

Rob Kaper said, "A few of the applications kappfinder looks for are Konsole (erm, terminal) based applications (ncftp for example). I think it would benefit the user if we group those in a "Konsole applications" or "Terminal applications" submenu because these are a completely different type of application and would probably confuse beginning users. Good idea, bad idea?" It was generally agreed that this is a very good idea and was added to CVS in kdebase/kappfinder/apps/Internet/Terminal.

10. Use of Konqueror in Kiosks

14�May�2001 (8 posts) Archive Link: "[Fwd: Using Konqueror in Kiosk mode]"

Topics: Konqueror

People: Cristi�n Mej�a,�David Faure,�Michael Reiher

Konqueror continues to spread in usage as it becomes a more capable browser. Since browsers are used just about everywhere these days, it was only a matter of time until someone wanted to use Konqi in a kiosk. That day arrived when Cristi�n Mej�a wrote to Michael Reiher (who then forward it to the kfm-devel list) saying, "We need to install several low profile machines for a kiosk network that must be fool-proof. We love th KDE environment, and instead of using the standard kiosk config (with netscape 4.x) we want to use the Konqueror browser. But, for this use, we need to start the app in full screen mode and with the right mouse click disabled. If you know that this is possible, please let me know!!, I can arrange some support for your work (maybe not too much), but will help all the GNU development."

In response David Faure said, " You can use the "dcop" or "kdcop" tool to activate fullscreen mode automatically, but you need to hack the source if you want to disable the right-mouse popup. That's as simple as commenting out the connect()s to the "popupMenu" signals in konq_view.cc" Michael then asked if it would be appropriate to add an enablePopupMenu(bool) dcop call to Konqueror. In reply David said, " If it helps anyone, yes. But is that really enough ? As others said, there's probably much more to hack to turn konqueror into kiosk mode, no ? My point is, if it can all be done with dcop calls, then that's great and let's go for it. If hacking the source is needed anyway, then one dcop call instead of a patch won't help much." Michael agreed with David and clarified what he intended to do saying, " My intend was to provide a patch which adds a dcop call to disable menus, first. So we could "collect" some patches that are neccessary to get a proper kiosk mode as the need arises. All accessible via dcop. So some day there is a sequence of dcop calls to make a konqueror run in kiosk mode (or perhaps provide a goKioskMode() call for convenience)."

So while Konqi is already partly ready out of the box for true kiosk mode it looks like it will soon be possible to send Konqi into a full kiosk-style browser mode with a single DCOP call. Very nice.

11. KDE 2.2beta1 Code Freeze

14�May�2001 (5 posts) Archive Link: "KDE 2.2 beta 1, freeze"

Topics: Release Schedule, KDE 2.2

People: Waldo Bastian

The time is approaching for KDE2.2 to see the light of day, but we're not quite there yet. Waldo Bastian announced that CVS was feature frozen for 2.2beta1 saying,

I will tag CVS on wednesday evening (that's thursday morning in Europe). Once CVS is tagged, only bugfixes that need to go in the beta release should be committed. Once the KDE 2.2 beta 1 has been moved to the ftp server, CVS will be open again.

After KDE 2.2 beta 1: After the beta CVS will be open again, but I would like to urge everyone to concentrate on bugfixing and speed-issues from now on. Translatable messages will not be frozen until KDE 2.2 beta 2.

This prompted the usual flurry of messages outlining remaining issues in CVS that should be fixed before a release and which ones would not be ready in time. We look forward to the release!

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.