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. 😉


13 thoughts on “Network:/ kioslave entered kdereview

  1. I still think that a polling backend would be quite important for the time being. It could check if the local network has a reasonably “small” netmask and just scan it – not too fast and not too slow, say 30 IPs per second. That way one could find SSH/SFTP, FTP, HTTP and some other services not usually using discovery. Polling is going to be somewhat messy of course.
    Do you know if Zeroconf and / or Avahi support discovery of *all* services or just some modern ones, btw? How widespread is it?

  2. @Andreas: I would agree. Especially as I see none of the Windows computers in my home net, just that I do not feel sad about this 😉 If you or someelse could do the lisa and/or the smb backend for the network library that would be cool. I would be pleased to help integrating it.
    Zeroconf supports discovery of all services which use it. How widespread it is I don’t know. But it seems to increase. And should, as it is quite useful.

  3. Saw some Nautilus code which assumes “_ftps._tcp” to have the same data structure like “_ftp._tcp”. So some support along that way is commited now. Your ftps server just needs to use zeroconf and announce its service, then it should appear in the network:/ kioslave.

  4. @Andreas: see old ‘service-discovery’ branch for example of port-scanning backend:

    ‘srvdisco’ subdirectory contains ‘lisa’ engine used to find ‘scopes’ – places where services can be found (in this case it uses old lisa daemon from KDE3 to find all computers on the network)
    Then portscanning engine (‘portscan’ subdir) searched for ftp,www,telnet and ssh services in all scopes found by lisa engine (or any other engine capable of finding computers on the LAN)

  5. @slubman: Not yet. But one day I would like to support that, too.

    @Kuba: I should really some day explore more than just the IDEAS file in that branch. Or pull you into a longer chat session 🙂

  6. @Angel Blue01: The remote:/ kioslave does
    a) lists static service urls (ftp, webdav, smb, fish)
    b) forwards to other specific service discovery kioslaves (zeroconf, smb, …).
    Point a) is just another bookmarksystem. Point b) presents technical details to the user he might not be interested in.

    The network:/ kioslave now does work similar to b), it just integrates all the different discovery system into one view, without disturbing the user with all the technical terms. Additionally it tries to map the real world with devices and services running on them into the used hierarchy as close as possible and to offer the items in an object-oriented manner. For now the network:/ kioslave is limited for ethernet networks. IIRC Bluetooth is rather a 1-to-1 connection, and also has quite different concepts, so mapping it onto the network:/ kioslave will not work. So special tools like this are better:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.