Network:/ kioslave entered kdereview

While today those lucky enough to be chosen for participating in GSoC can start their activities, we all wish them much fun and pleasing results, others can mark an end to a period of development: Not just kdelirc did enter kdereview and now awaits your critics, also did a so-called network:/ kioslave I have been working on in the last month.

Read on for some background about this kioslave. This text had been written for the Commit-Digest but did not make it in time for the latest one:


The network:/ kioslave offers the listing of the network from a general point of view. It should map the physical world as much as possible, with all the devices and services. The main purpose is discoverability of what there is around the computer and object-oriented access to it.

It is a little bit in the tradition of the lan:/ kioslave, which is driven by LISa, but unmaintained for KDE 4. While LISa in it’s time basically had to use pinging, the network:/ kioslave now can use backends for the modern service discovery systems like zeroconf.


The network kioslave currently consists of four parts:

  • a library named network, which models the devices and services, driven by backends for the various service discovery systems
  • a mimetype definition file, which adds types for the various devices and services
  • the kioslave itself
  • a kded module to emit proper KDirNotify signals if the network structure changes, so all views using the network:/ kioslave get updated

Both the kioslave and the kded module link to the network library. Due to synchronisation problems the kioslave currently pulls the needed data from the kded module using D-Bus, instead of directly using the network structure in the linked-in network library.


The kioslave is already quite usable for networks with devices using zeroconf, like there is with KDE programs using KDNSSD/Avahi or all Apple computers. Even reacting to (dis-)appearing of services and devices seems to work flawlessly now.

All service types are currently simply forwarding to the corresponding url, if there is one. So for services which have direct support in KDE for the used protocol, like webdav, http, ftp, svn, ssh or vnc, you can click on the service item and then either find yourself listing the files, browsing html pages, login to the shell, or whatever this service and the (KDE) clients enable you to.

For some servicetypes you first have to assign yourself a handler, if the mimetype for the service could not be derived from a matching one, like inode/directory. For this goto System Settings>File Associations and see for “inode/vnd.kde.service.*“. E.g. for “inode/vnd.kde.service.rfb” add “krdc -caption "%c" %u” (%u is important) as application handler. So clicking on a rfb service will start KRdc for that service.

A little bit annoying can be that there is not yet a configuration to filter the presented services, e.g to hide all system-level and unknown service types.

And, might be a stopper for some, Dolphin and the Plasma Folderview widget do not cooperate too well, they often show some error messages if launching remote urls. So just use it in Konqueror for now 🙂 Well, other non-file kioslaves are affected as well, so one should see after that.

The network:/ Kioslave


Wide, wide open.

More backends are needed, for UPnP, SMB stuff and others. There is already a rudimentary backend for SLP, but this crashes due to threading problems (the kioslave ran the network library in a separate thread, until the current synchronisation fix with the D-Bus pulling was switched to), so the zeroconf one is the only working backend currently.

Supporting the display of the status of the service needs support, e.g. updating on the presence change in a Bonjour Chat service. And getting some Meta information for services to display, here the name and such.

Then I am looking for a service which can help to identify device types properly (printer, router, computer, laptop, phone, or handheld, perhaps even manufacturer/model). Currently the type is guessed by the services running,
which is not really perfect. Also it would be nice to have individual icons for the devices to display, similar like favicons are used for web services.

Next, things like virtual machines or PDF “printers” bear some challenges how to present them best. In general there needs to be a definition for what system is a device and what is a service. In that process the mimetypes for the services and devices also need some rethinking.

Also the network library needs to be checked if it could not end as a generic library to end in Solid or another place. And could substitute KDNSSD with a generic interface to publish objects/systems to the net or query/get proxy objects for systems on the net, including WebServices ( see also similar ideas from Jakub).

Furthermore, all programs which can connect to a remote source need to expose this capability also on the commandline, so they can be started explicitely for a given service. E.g. some KDE games are network enabled, but do not yet support to connect to a remote game by having the url passed as a commandline argument. I did a quick example patch for KBattleship, but it seems I need more motivating material for the KDE games developer 😉 At least this particular patch is now committed (during the Chemnitzer Linux-Tage I demoed the network:/ kioslave to Patrick and Eckhart at the KDE booth, which resulted in a KBattleship tournament, won by Eckhart with easiness.)

And in the end I would like to have some more spatial oriented views for hierarchical items, based on concepts found in the environment view of Sugar and the Semantic Desktop DeepaMehta, best automatically structured by using the geo information of the devices.

Seems it will be ready next week. 😉

Infrared control coming back to KDE4

One entry in the list of planned features for the module kdeutils reads

Bring back kdelirc

So this is going to become another example of the “just-put-to-hold-not-vanished” nature with FLOSS:
kdelirc, a tool to operate your programs by an infrared controller, had been lost in the KDE3 to KDE4 conversion. But Michael Zanetti heard the call for maintainership and jumped onto the code to make it ready for KDE4, for now in the playground section of the repository.

And a few days ago he wrote to the kde-utils-devel mailinglist:

I think we (Frank and I) can bring back kdelirc for 4.3.

He then described the current state:

– It is fully ported to Qt4/KDE4. No Qt3Support.
– We have heavily refactored/rewritten major parts because the original code was in a really bad state in terms of readability and maintainability.
– It is basically the same program as before. There are some new extensions and remote controls.

It is not 100% finished yet, but we’re on a good way. All the functionality is restored. We still have to do the following tasks:
– Finishing rework of kcmlirc.cpp
– Fixing some bugs introduced during rewrite.
– creating svg icons
– some general cleanup (krazy checks etc)

About the documentation: We still have the original one. It is not perfect but at least not worse than at KDE3 times. Perhaps someone has the time to help out here…?

To get it into KDE 4.3, kdelirc needs to be complete enough to enter the review section until April 20th. So if you are looking to do your presentations or tune your music with a remote control already with KDE 4.3 again, now jump in to fix the remaining issues as listed, e.g. the one of krazy. Get in contact on the kde-utils-devel mailinglist.

Start with just giving it a try. For your convenience:
svn co svn://
mkdir build
cd build
make install

KDELirc is part of KDE 4.3. Sources found at,
the homepage at

Interested in maintaining KCalc?

One of the powers of FLOSS is that if an author/maintainer has no more time or no more interest in some program that program does not vanish with the author’s/maintainer’s change of focus. It’s development/maintenance is just put on hold. Until someone else takes the sources and gets things back into rolling.

And now let’s see how short the time of “put on hold” has to get for KCalc. David Johnson, who has been giving his care for it since more than a year, making it one of the good KDE4 programs, now had to write to the kde-utils-devel mailinglist:

Real life has been intruding into my KDE time. While I still plan to help out KDE, I doubt I will be able to adequately support kcalc. So I’m putting out a call for a maintainer.

This isn’t urgent, but if you or someone you know may be interested, please contact me.

Contact is done with an email to david at usermode org. I hope we soon can welcome someone new to the little team of developers in the module kdeutils, do not forget to join our mailing list and say “Hi!”.

If you like some inspiration: One interesting challenge might be to factor out the calculation engine and share it with the calculator plasmoid. And an option for a prompt history display would be great to have, too.

Currently it is even possible for you to do new features for 4.3 with the Soft Feature Freeze yet coming at Thursday, April 16th. So think about, if KCalc could become your program for some time 🙂

How do you do remote presentations?

Dear lazyweb,

have you ever done a presentation or given a talk to a remote audience, via the internet? Or setup an infrastructure to make this possible?
Which software did you use, which setup, which protocols?

What I am looking for is

  • something like a one-to-one video chat with an extra channel for a (shared) screen,
  • just that the “one” on the other end is a full room with people, caught by a camera and some microphones feeding a single source.
  • The (shared) screen would be given by the single person end, for the interactive slides and demos.
  • Bonus points for being able to show little movies over the connection.
  • The multiple person end would be able to overlay the video of the single person to the display shared screen locally, either by a second projector (second head/screen to the computer) or as a little window on the first screen.

This should be really possible with today’s FLOSS software and the common hardware. But how?

Thanks for your hints.

PS: Reminds me of what somebody told me a few days ago. Yamaha builds pianos with which one can give remote performances over the internet, due to the mechanics being controlled by commands recorded from the sensors on the other’s piano mechanics, see e.g. this video. And, FWIW, it’s built on Linux 😉