Stories of a KDE programmer

KaNDAS, KaNDASd, and KaNDASconsole 0.1beta1 (aka 0.0.81 for package management systems) have been released:

• Source tarballs
• openSUSE 10.3 packages
• openSUSE Factory packages

The latter two links are repositories, add these to your repo list.

Yesterday I said that only state transitions in KaNDAS are missing for a release. Today, I can say that state transitions are available in KaNDAS. I did also write an init.d script for kandasd to allow it to start automatically when you boot your computer. With these changes, everything is in place.

I’ve written a release schedule for KaNDAS 0.1, KaNDASd 0.1, and KaNDASconsole 0.1. After one week to cool down from the recent development, Beta 1 will be tagged on Friday and released on Monday. In the mean time, I’ll try to set up a repository on the openSUSE build service, which will enable me to build packages for openSUSE, Fedora, Mandriva, Ubuntu, and probably some other distros I did not mention.

The complete release schedule is available on the project page.

Of course, my NDAS device is located at home. But my notebook, where most KaNDAS development takes place, is designed to be mobile. I’ve decided to make my NDAS device mobile, too. It is not in my bag, but on my hard drive is KaNDASsimul.

Like the name indicates, KaNDASsimul simulates NDAS devices (or better: NDAS drivers). The KaNDASd daemon gets all information it needs from the /proc/ndas tree which is generated by the ndas-core kernel module. KaNDASsimul generates such a tree from the commands one enters on its CLI. The only disadvantage with this approach is that you have to do state transitions (namely connection and disconnection of devices) manually as KaNDASd is not able to know whether its source is real or simulated and that is good of course; simulation is a development tool and not intended for a mainstream release.

Talking of a mainstream release, you might have noticed that there have not been any until now. I’m simply busy with real life issues. The only thing that is missing for a first release is the invocation of state transitions in KaNDAS (and some bugfixing: it does some quirks while loading). If everything goes well, KaNDAS, KaNDASd, and KaNDASconsole will be entering the alpha phase before the end of this month.

From earlier blog posts, you might have noticed that I’m working on a project called KaNDAS. I did not write much about what it really means, and the official KaNDAS page is not very helpful for newcomers. Therefore, I’m going to provide an overview of nearly everything you need to know about KaNDAS for now.

History and program design

First of all, KaNDAS is not a monolithic program. In fact, it was when I wrote it first. The problem I had is that I own a network-attached hard drive from Trekstor which, for Windows, has a nice GUI with a tray icon. The software provided for Linux are: a kernel module and a command line administration tool (only for usage with root rights). Not a very friendly situation. The whole interface I have is /proc/ndas and this tool which allows me to start and stop the kernel module, connect, and disconnect devices. At first, I wrote a simple GUI with five friendly buttons for these actions (connect is two actions since one can connect read-only and read-write). It was called KaNDAS which is an abbreviation for “KDE adapter for NDAS devices” (the “adapter” is type of a backronym; I chose the “a” to have an easily pronouncible name). This simple approach had some big deficiencies: It could only handle exactly one device, and it was, well, too simple. It did not automatically adapt itself to external changes, for instance. The biggest disadvantage, however, was that one needs to enter the root password for every single action since the admin tool requires root privileges.

My solution to these problems is a client-server architecture: A daemon called KaNDASd (d = daemon, obviously) is running with root privileges. It scans through /proc/ndas to detect any changes on the devices. These changes are propagated using a D-Bus interface on the system bus. This interface can also be used by clients to invoke status changes, e.g. when you choose to connect or disconnect a device. This has two advantages: You do not have to enter the root password every time you connect your device, as the admin tool is started by the root daemon KaNDASd; and you can use two different clients at once without having them both to scan for changes.

So, it is very easy to have multiple clients. By now, there are two clients available: KaNDAS itself which is a KDE 4 application with nice list views of all available devices and all the well-known KDE4 goodies. For fans of scripting, there is also KaNDASconsole available. KaNDASconsole is an application suite which consists of three tools at the moment: kandas-info lists all available information, kandas-up connects devices, kandas-down disconnects them (naming in resemblance to ifup and ifdown).

Installation

KaNDAS is in development at the moment, there hasn’t been a release yet. Therefore, you’ll have to get the sources from my version control system. Create an empty folder, open a console in it and say:

svn checkout http://kandas.googlecode.com/svn/trunk/ kandas-trunk

This creates a directory “kandas-trunk” with three subdirectories for each application in the KaNDASd family.

For compilation, you need Qt 4 and kdelibs 4 installed, along with the development packages. At first, you’ll need to compile KaNDASd as it installs header files necessary for the client applications. The build process is as usual with CMake. Go into the kandasd subdirectory of the downloaded kandas-trunk directory, create a directory “build” in it, open a console in it and say:

cmake ..
make
sudo make install

The output says where the “kandasd” executable is installed; you’ll need this path later. Proceed with compiling kandas-console and kandas in the same manner.

Usage

At first, make sure that your NDAS driver is installed and started, and that you have registered at least one device (unless you want to see empty lists). At first, you’ll need to start the KaNDASd daemon. To start it as a background service, use

sudo /path/to/kandasd --detach

If no output appears on the console, the initialisation of KaNDASd went well. You can now view the available devices and their slots (which are connection points which you use to connect to this device) by running kandas-info. (KaNDAS-info displays quite much information, use its command line options to lower its output.) If there is, for example, a device “Cookie” with the slots 1 and 2, you can use the following commands to connect to and disconnect from your device:

kandas-up 1 #connects slot 1 (read-write mode)
kandas-up -r 2 #connects slot 2 (read-only mode)
kandas-up -d Cookie #connects all slots of device "Cookie" (read-write mode)
kandas-down 1 #disconnects slot 1
kandas-down -d Cookie #disconnects all slots of device "Cookie"

Everything after the number sign is a comment. I tried to align them with extra blank spaces, but WordPress removes these. (Time for a bug report…)

Aside KaNDASconsole, there is KaNDAS which has at the moment about the same functionality as KaNDASinfo, just nicer. There are already buttons for connection and disconnection, but these are not working at the moment. Once they are, I will prepare a first release to spread the word of KaNDAS.

The KaNDAS project

If you are interested in helping KaNDAS, this is your chance: It’s one of the project’s goals to integrate with your personal workflow and environment as much as possible. Due to my own limited spare time and programming experience, I’m in need of more programmers to extend the team:

• A GTK+ programmer with D-Bus experience is searched to create a client for GNOME.
• A Plasma nerd is wanted to work on a KaNDAS plasmoid. (I think of a user interface boiled down to only one device as users own only one device in most cases.)
• Of course, you can come up with your own ideas to make KaNDAS rock. If you’ve found a bug, use the issue tracker on the project page.