To solve the problem, I’ve written two small Python scripts. obs-addrepo wraps zypper addrepo for Build Service repos:

# before
$ sudo zypper addrepo http://download.opensuse.org/repositories/Application:/Geo/openSUSE_12.1/ Application:Geo
# after
$ sudo obs-addrepo Application:Geo

obs-quickinstall is the 1-click installer for command-line users:

# before
$ sudo zypper addrepo http://download.opensuse.org/repositories/Application:/Geo/openSUSE_12.1/ temp
$ sudo zypper refresh temp
$ sudo zypper install --from temp josm
$ sudo zypper removerepo temp
# after
$ sudo obs-quickinstall Application:Geo josm

Both tools are now available as the obs-tools package (Git repo). Packages are currently building on the Build Service, the project page has installation instructions.


[system]
name=example2
r1=1.0
r2=1.5
V1=-0.05
V2=0.1
[...]


Nothing exciting there, reading this is a breeze with QSettings. Now I needed to do some symbolic calculations, for which I chose Python and the excellent SymPy module. To read the system configuration, I chose the standard ConfigParser module.


parser = ConfigParser.RawConfigParser()
parser.read("scatttd.conf")
sysType = parser.get("system", "name")
# read system parameters
sysParams = dict()
for key, value in parser.items("system"):
    if value != "name":
        sysParams[key] = float(value)


That reads the “system/name” key, and puts all other keys (which are assumed to be floats) into a dictionary, so the system-specific code does not need to deal with the ConfigParser object.


r1, r2 = params.get("r1", 1.0), params.get("r2", 1.0)
V1, V2 = params.get("V1", -0.1), params.get("V2", +0.1)


This code gets the parameters in the system-specific code. Nothing exciting here. Except, stuff doesn’t work. The results of the following calculations suddenly don’t match my expectations (or the predictions made by my other programs).

Since the code after the snippet above is about 30 lines of SymPy magic (accumulating expressions that print dozens of lines onto my terminal), I suspected that some error occurred there. After about two days of searching for the problem there, and calculating everything by hand, something occurred to me when I looked at the debug output:


DEBUG V1 = -0.1


Didn’t the configuration file say “V1=-0.05″? Let’s have a look at the parameter dict:


{'v1': -0.05, 'v2': 0.1, 'r1': 1.0, 'r2': 1.5}


See the problem? “v1″ has a lower-case “v”, so params.get("V1", -0.1) fails and returns the default value (-0.1). One glimpse at the documentation says that


parser.optionxform = str


solves the problem. Gah!

Can we improve on that?

Looking at my desktop, I see the “Now Playing” applet. It shows the current track from Amarok, and has the basic media player controls (pause/stop/previous/next + seek slider + volume slider). Again, this is about all I need for an user interface while my playlist is filled. I remember that the nowplaying applet communicates with Amarok via DBus using the MPRIS (Media Player Remote Interface Specification) standard.

With all these impressions in mind, my target is clear: I want a headless media player which runs in the background and offers an MPRIS-compliant control interface on DBus. Something with a smaller memory footprint.

Intensive searches on the internet did not turn up anything of interest. Of course there are command-line music players (e.g. MPlayer), but those expect to be connected to a terminal for control. They cannot be run in the background, and there’s no nice GUI for them (like with the nowplaying applet). It looks like I need to do it myself yet again.

So here is the Raven Music Server (called ravend for short, as it is a daemon), which is now publicly available at git://anongit.kde.org/scratch/majewsky/raven. It currently implements the basic interfaces mandated by MPRIS version 2 (unfortunately the “Now Playing” applet supports MPRIS 1 only). The biggest missing piece is support for editing the track list, so at the moment you need to restart the process to change the playlist.

I have been productively using ravend for two weeks now, since one day after its inception, and I’m quite satisfied with it. And now that it is in a public Git repo, you can, too! Provided that you find pleasure in controlling your mediaplayer with commands like

qdbus org.mpris.MediaPlayer2.ravend /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.PlayPause

Convenient user interfaces will become available, eventually. Even then, the Raven Music Server will probably not be interesting for end users. Power users may find this project interesting if they like to keep an eye on their system’s memory footprint, or want to have their playback continue even when the X server is terminated, or want to run a full-fledged media player on a headless system.

The Akonadi server is only started when some application needs it. So who wants to communicate with Akonadi? After some search, I found that the clock applet on the Plasma panel is the culprit. It has a feature to display events from the Akonadi calendar which is enabled by default (and I don’t want to oppose this choice; it’s a very nice integration feature for people using KOrganizer).

So if you want to prevent the Akonadi server from starting on systems where you don’t use Akonadi, or just want to speed up the startup of your KDE session by delaying Akonadi’s startup until it’s actually needed, do the following: Go to the configuration of the clock applet, and disable “Display Events” in the “Calendar” section.

To check whether Akonadi is running, open the “System Activity” monitor with Ctrl+Esc (or by clicking on the second icon from the left in KRunner). Look for a process called “akonadiserver”. (There will also be multiple processes with names like “akonadi_agent_launcher” or “akonadi_whatever_resource”.) You can also manually start and stop Akonadi with the commands “akonadictl start” and “akonadictl stop” (from either the command line or KRunner).

A major argument for reusing passwords is that one can’t remember dozens of passwords for all services one uses. The typical counter-argument then is that one can use a password storage, be it a local application like KWallet or an online service. Such services allow you to protect multiple different passwords with one master password, which is the only one which you have to remember.

I am personally a user of KWallet, and must agree that it’s a great relief to have a backup for this crucial data available anytime. (Currently, KWallet stores over 200 passwords on my notebook alone, and there are probably unmerged passwords over at my desktop.)

But alas, both kinds of password storage solutions have a big problem: KWallet and friends are useless when you don’t have the wallet file around on the computer which you are currently using, you’re stuck. If the only computer carrying the wallet file gets broken, you’re totally lost. On the other hand, online storage solutions require a big deal of trust towards the provider running the service. As we saw earlier this year with LastPass, this trust is in general not justified.

So what can be done? I just had an idea which I did not see before anywhere. (Might be that I did not look closely enough. Please tell me if this idea has already existed before.)

If we don’t want to store passwords (because that requires both the availability of the storage and trust with a provider of this available storage), we need to generate them based on an algorithm. In other words,

#!/usr/bin/env python2

import base64, getpass, hashlib, subprocess, sys

def doHash(x):
    return base64.b64encode(hashlib.sha512(x).digest())

def sendToXClipboard(x):
    subprocess.Popen(["xsel", "-i"], stdin=subprocess.PIPE).stdin.write(x)

try:
    site = sys.argv[1]
except IndexError:
    sys.stderr.write("Usage: %s [domain]\n" % sys.argv[0])
else:
    masterPassword = getpass.getpass("Password: ")
    sitePassword = doHash(doHash(site) + doHash(masterPassword)) # variant 1
    sitePassword = doHash(site + masterPassword)                 # variant 2
    sendToXClipboard(sitePassword)

This Python script reads the name of a website, and prompts for a master password. It then combines both using a considered-secure hashing algorithm (SHA-512 in this case), and sends the Base64-encoded result of that to the X clipboard (so the password won’t be displayed on screen). Base64 is the best compromise between printability and string size.

The code shows two incompatible variants of obtaining the sitePassword. I won’t debate over which is better. The extra hashes in variant 1 are, strictly speaking, security by obscurity, as they don’t help when the attacker knows the algorithm. However, that’s not the main security feature. As far as I can see, this algorithm relies solely on the strength of the SHA-512 algorithm, which is (as of August 11, 2011) considered secure, and (if the attacker is brute-forcing) on the strength of your master password. So don’t choose “correcthorsebatterystaple”.

What you see here is the very first steps towards systemd integration in Qt. I’ve started to build a libqsystemd, which wraps systemd’s DBus API into something which can be used by Qt applications. The screenshot shows a simple QML-based Plasma applet reading information about available systemd units from a simple dataengine.

At the moment, the library can only list available units, providing about 60% of the info which you would get from `systemctl list-units`. But adding more functions should be trivial now that the foundations are laid.

The only interesting point left is how different privilege levels will be handled. For example, only root may activate and deactivate units, initiate system shutdown etc. Most properties are even read-protected from normal users.

Of course, providing a library interface is only the first step for systemd integration with KDE. The second step is to actually use it. For example, systemd provides standard interfaces for setting the hostname, timezone, etc. in a desktop-independent manner. systemd can in the future also be used to coordinate the startup of a KDE session, and thus replace parts of startkde and kdeinit.

Can we combine these observations into an interface that saves space, yet is as approachable as a simple toolbar? We can.

In the back is the normal menubar/toolbar chrome. In the front is my first draft of an “Active” version of it. The menus “Game” and “Move” are completely gone, all contained actions are now on this first level of the toolbar. The “Settings” and “Help” menus have turned into toolbar buttons. Upon pressing one of these, the toolbar descends into that subcategory:

After selecting something from a subcategory, the toolbar automatically returns to the default category. For example, if you click on “Settings”, then on “Configure KDiamond”, the theme selection dialog comes up. When you’re done with that, you come back to the main window and find the default toolbar with the relevant New/Pause/Hint actions again.

What do you think? A first step in a good direction? Something you would even want on the desktop? Or just plain awful? Please let me know. BTW the source is available on ReviewBoard.

P.S. To get that straight: This is only for games with a small set of menu actions (about 28 of 40 KDE games, according to my counting). Apps like KGoldRunner or KTuberling just don’t fit the idea behind this proposal and will therefore not be affected.

P.P.S. I’m aware that vertical space is still wasted. I’m going to experiment with moving the toolbar to the side for displays which are wider than tall.

These days, I’m usually working on my Diplomarbeit at the Institute of Theoretical Physics at the Technical University here in Dresden. (A Diplomarbeit is about comparable to a master’s thesis, though preparation time is one year since there was no bachelor’s thesis before it.) Our working group has an in-house application for inspecting iterated functions, which is quite intuitively called Iterator. Like many scientific applications, it has on one hand a very sharp functional objective, but contains tons of different tools and plugins.

As a part-time project besides my usual work, I’m working on a Qt port of the Iterator, which is currently based on wxWidgets. Of course, a port offers the opportunity to refactor badly engineered parts of the application. It clearly shows that all involved developers are first and foremost physicists which have not received any formal training in software design. Many antipatterns can be observed in the code. The most interesting is the existence of a god class called IteratorApp.

IteratorApp is not the application instance which drives the eventloop, as one might expect from the name, but the main window. The iterator.gui.iteratorapp module imports about all other core modules, and instantiates them inside the IteratorApp class. The reference to the IteratorApp class is then passed around to all components inside the IteratorApp, and also all plugins loaded by it. The IteratorApp also contains most of the basic business logic: loading of plugins, creating and managing all widgets in the mainwindow, etc.

There are evidences that it was even worse some years ago. People have already worked on extracting modules out of IteratorApp, but they are still closely tied to IteratorApp, and thus have direct connections to all other parts of the code. The most interesting thing about this design is that the Python programming language makes it very hard to discover dependencies between modules in this design. Consider the following Python code:


from external import BarComponent

class FooApp(object):
    def __init__(self):
        self.bar = BarComponent()


FooApp is our equivalent to IteratorApp here. Now when you have a reference “foo” somewhere, “foo.bar” will give you the corresponding BarComponent instance, which you can directly use if you need functions of BarComponent. You can also pass it to other modules with different variable names and stuff. All this makes it quite hard to track efficiently on which components the specific module you are looking at depends. One can grep for “foo.bar” if “foo” is the established name for FooApp references. But if you pass the BarComponent reference to some other code, this also won’t help. The problem is that you do not need to explicitly import BarComponent like in FooApp. This is a non-issue in C++, where used classes are usually forward-declared:


class BarComponent;

class FooApp
{
    public:
        BarComponent* bar() const;
};


If you use methods of “foo->bar()” somewhere in your code, you absolutely need to include the BarComponent header. The dependency of the component in question to BarComponent is then obvious. (Executive summary for this part: Forward declarations are good not only for reducing compilation time.) How can we transfer this advantage of C++ to Python?

The Qt port of the Iterator does not include something as powerful as the IteratorApp. However, in an application consisting mostly of plugins (i.e. the iterable functions, and the tools that the different group members use to solve their distinct problems), there must be some authority that keeps everything together, and which is passed to plugins. In the Qt Iterator, this position is taken by a new PluginLoader class.

The PluginLoader itself is – on purpose – very light-weight: Its tasks are restricted to creating application-global instances of other classes which are called application plugins. For example, the Qt main window is an application plugin. One can ask the plugin loader to load a specific plugin by calling it (i.e. its __call__ method) with the type of this plugin. For example, to instantiate a PluginLoader and get a MainWindow from it, the code is:

from iterator.common.pluginloader import PluginLoader
from iterator.qtgui.mainwindow import MainWindow

pl = PluginLoader()
mw = pl(MainWindow)

The plugin loader places a reference to itself in all loaded plugin instances in the “pl” attribute. This behavior is similar to the IteratorApp, which distributed “app” references all over the place. The important difference is that all business logic resides in application plugins. These can be obtained from the plugin loader at any time, but using a syntax which requires to name the type. Naming the type requires the Python developer to import the type explicitly, thus making module inter-dependencies visible e.g. to automated dependency graphing solutions, which can, as a follow-up to this initial refactoring, be used to decide on subsequent refactoring steps.

Along with the plugin loader, I defined (and documented!) a simple protocol which plugins must follow. This protocol defines a common set of functions which plugins can implement e.g. to be stopped at runtime or to get notified when other plugins are started or stopped. The latter allows for optional dependencies between modules. This protocol allows for some nifty features: The plugin loader installs a sys.excepthook and stops interface plugins which throw unhandled exceptions. The exception and trace is displayed directly in the interface, as can be seen in the lower right here:

The PluginLoader has been designed with the migration path from wx to Qt in mind: It has no Qt dependency, and can also be used in the old Iterator. (Legacy installations might not have PyQt available, so Qt can only be an optional code path at this point.) In fact, some of the new application plugins, which are used for internal data management, are also used in the old IteratorApp now, although the data is additionally made available in the old attributes for compatibility.

For communication between application plugins, Qt signals/slots have been chosen. As these are obviously not available in wx or Python itself, I’ve written a basic, sufficiently source-compatible implementation which is used as a drop-in replacement in non-Qt environments.

Here’s the source code for the plugin loader (minus some highly application-specific parts like plugin shutdown, which can be easily inferred by copying the startup code) and the platform detection including optionally Qt-based signals and slots. But I cannot upload text files or tar archives here in this blog, and any linked external source to which I upload the archive file can go away any time, which I do not like. (I tend to get mad on 404 links.) I therefore insert the BZip2-compressed tar archive as Base64. To get the archive, copy the following character block into a file e.g. “foo.txt” and then do “base64 -d foo.txt | tar xjf -”.


QlpoOTFBWSZTWawqqUsADKD/pPzURwB49//fL+/9qv////ACAAABABhgDTy3zMBQbWew72mxqou8
7jWp6xSBUlaZ7zdm1p7tDEhATRpkZUeamJpDT1GgDR6gyAAD1DTT1GjQaAITEmlPTIJkmQA0GgAa
A0AAANANTGkqejU00GTQNA9QxAAAANABoaA0ASakImgmhqYahkepkoHpBp6mmh6jQ0AAMEZNBxoa
Bo0yNNGmQGJggABoDQGmQGBMgSIhNBNE00DU1PTKm9ARqGnkj1PEgaAA2p6Q9Q0f+/uH0zzeecsf
MDzKhAdUhJMeKdQekPCTTwPHxq2fkQ1iCaAgwgJJBKjIEWBOf0+hbnv6hGh6WzefYFqBjVkhkEyH
04xG5yhG/lSez3pwNXqCcEp3/oeAtyQ547/3Nu3HhTqgK/JlMSeJ9X79ot4/8mFbZE6UrP2TVtJs
Zzbzffe7Nl3RG7oeX27rljc9a760Nj198GP9rTv3dYjsQ0JCNgMQkKqARkCJII6VN83ydYVhnZpB
bTVgiq5WkOEsVUyhE2a5oUDrZxnrtwbBLjzbgSVpvIKgcMcAi6IqOMzsISIwZjjv7P3ASvZWg7n6
xHSLIi5W+CUzyTgWMnsulqxDqcG++B1dt5PqVVtvReKIqrfnZJOTkaC9asA6ar0GFzXU6g0ckLfC
1dYVHCw3JwhqEymzaHhiRmhUZIvl6bHDHzRrnrCC8Dgcy6jNpN2u2z7UDJmQzeJyVTjCRJ04bLtG
9rZ2Ota33lbJ3eW6174uEFHsubFxlsGE7V8NwMnqzsNcTIa434nTit1NKYBuG0u1OkRfc9ASsk8H
7x5VCkHbr1djN9S5BNzJ0Oi8c9lUkKU1QzTOpuEuN1AlZmxudefVBPL8SiQhNC1WvoR6rVgdhiuk
BqacOoQ1lX4cDZUQ9xkZ1ZNCVM1xyvcKdOEWg08waNN6VY7kdmTdRxB0sBTx+OILQwnSR5PA0OLc
oxxZz1TvWDK+uFO6Gq+GKwzI2iC7w5yluGM1BnigbRKPzhE0SAinYLnDBzUwlUWGVVo5h5oUhqJe
mDowwFQcxHmmHEyek2ZbKlnF7pacdmc627DtR4CSEBlhAkeQt42eZH3EkCfeu5dfWw4+mJScSBcE
Z/EkwRnTM7gAVHNVhGSRjisFUWCDlLjpGuctck4cK41rPTi2xqlHkrFKRDg4UK+nmGcpJYTEJz9v
ZTKHXZPTUDA6k1MXUy/xEGSRO+EcZ5jy3nDoHCT8o9OetS1sFQ3QzQYfVsGrnKGuyCijJgrzAS0p
ywHNLfyToz8MEtRBosyuxkZlKzwWpAnR9BfPkEWxIOI7rMY7ddoXDiQTbhEgww51+O5t9QIPGFPH
T9tAPWFg4MJYNPbiDyVw2B7rGAMtAaTINGWRgEXpVs+qmz64vYaXFFu424hotuk4B7dugVddGFrn
xTthk10l5oGJJiFojjvm4ssm9oTiXJz86neBCFwcILop4Q3azHDQ49UU3TGh709p5QD3DDHtnwhD
2GYiDhd5uhQJE0+05yhy1Shbz3/A9VViMRUH7jvP7ki14n1HwR+FTHxacJG07tGUQ4IzfwLKfRnu
LF8qLNgnRWBlNo9dUPzn4C3xn4jifjRjC52aoTidf0Y2p5FkxR3coF4RsRdCsYuDbpEoB2iwOExr
uR8KvZAgLwyBGQnEJLiEAa/XcU/PCGekUyeBayOARBhps9wj/SPasa/fk36MPzvGIBa+/YvQIoFW
L4BqjbJ6wsjVIuls7e+Sn6yDbnQXqoLiwvQN5Pu+9iet/WaVprldhrJDgc2eIUpXzlTpz4qQWZUY
NtNnV1nVhJIyzYsKLgs1plQaMhc9thwR+qd0nZwh28tlHoqTtSLJteHxh7SbIIxTOSbGKytSIPyn
l8VDNpDqHUX7uDBexdEUKloGdblNtDFWbfY1lKC9CUh5nrjVNQPbpU6TQk2OxWQUdtDla0Lj3t1B
lCUwVq1FhWMDwqoC53OaBou7jmWPLXDOCiyN62wbFrBwdU+TC7nAGiUfYaiMN9LEOODOU49XZh4X
FBCIIhQF1BfoMwbNRYxeEzQuyQipCJEqTUCJjDZlKJE5vV+rEr43pYXzDGxgBoKXYFreZSa5xeGu
Z2Glw6568Tg6g7KYPRSvesIatpNHOrzPdpNWY6jQzshuNZfG76iF2zWTKYgwc71y19GM8Bw31sg5
oyOFyaj5bzEwq1rO05ngCwC8PB0JkBVnw9pbk35Hg6xuuk2OlraDiuteZHLGdawMOkLwnlHljKlN
lIkMoDNhRhRLllQXIKcoHvWw6bi1+LtWX7YstOo92dxRSwoNg/sXmlRUpmEIfTySHDk3RbgGXT0/
et3sOg+OW7St6EnEGNwQexkmTCkujSpKsSGJyMBzvnyNLc9Q5vW1L8YZUYUD5fZaTFAYxaEkxopZ
U6eKgw7EAiDCdTeQnbDdDuEYKGSyVImxGoQ98GLILd9QxSRRgNhQSm3CZGyewZpMgBXY6LQs5LYQ
ItOm+6iwZw3JlDBZW5HwdPLhIAm8YHUKxYLEm/6Z3EOnx4w0nZugcz3wWAsiJtJiEXAj2o6tHTy4
7+qDx7PLUot3A60cF6A3ciRqxd0ngYWYWGF0LtgzEbkzPOho0NjBsaPjqRX59/RQOkG6hs5jmFPX
biDwXV0GMbLKBl4h0FeTXnY+b4MvFExQj62hYrLRlMjoA2SriV7SjzwGYS7SiH2UlEsuCk2SPauw
BUWRjpmyG21WEK9IWVhbwbGsfyHYAabtNIFpoV2xDdPcyKEUUUUFgCCQVYM9m7TXtq0763k27oC5
9kPTOg4uXDPnaouXu3qzVWh8HxGJcDzJi2RD742upoJNAvkIbMqZcVu2CmC0wplqzcXxarMshZMW
vamXQFEQgpA6IQoYbTKYYXGUddAUIKmVMLgiCmh0wmq+l80LQFa5gh3okUQEoqI+apAfSdoogwwa
MmlkkCxrqAiIy1qKJpe9rpOoPchOSd3bQdF15e2wbFgjztjSbUCe5HSmqlvJ1IJIokssniIzMGXD
dsxcYjHq4JZBtB6jjZnIY9zIZofmmhstlHeUquTDGqJcNRdOZKhnyCc/NxgIIw3+g13EOCvw4uLC
ZE8eiOzq6Tdv4IudS5G2INeD/wO+iRn5jwGLMarmv8h8kBf0h9vpNxtMZT0oZsJxRH7i+Wse/e0w
iNN2foPr2befmwxg0gClHsjUegjRrHCAkJBoEpYi4DKcpUcZjgmjO3zk83b58Vt2LvglQRFWOVU8
6FRFPRECnEGooyWvVM5WuGBj8tFLHDj5u9XudmFjhCg8O84Tz7ANooQsDVGYpX4hecRbVUvh9CxF
MgNg8WhGB7Fn9APBVKrIPJ1VKM4SpUOgxDgJFWkcgoQ5RQc9yoUKQiqHVQEWVYK8sFo6itEelYcS
0OxqFV17qeAjoZt3Y3YmIvDqRaD1iYqa0DlgqE+plvywCl2HW6gFzqOjpmHJYNOaekN0AaDGNbe2
F357CTFsM8JDRm0JrYI4w2NkhhJYKnLvCr48AeRe5vo67IGHNZiAuxl4h2i5ENLRrSikGsRmIMus
5ZxKybhujRngGFgKsWCTEOjupKDOKR/zVcQhugQA2QTeVI7u1mj0oiS1KNIgaLtoqFbmKCe6KijB
Zu1zYhvTF89m/GLlXsGvwL7N8bknINEaNDlCPE0CjTKEiSWPw2uK9kBEDsJMVRBrJahe4LVBELkY
gosAp7nVCGeXS+tyzpMsgGMNESa7Vg0A0srZ6IPXlqt3y5ELIIOedswCEfcZfMR0Y5rxIIJZa4tI
YI1MEyAYnPNYRw/4B/qm5wNYtdWBqn7QCKVlG+qq2yqKJHB5S12rXOa+4ulUIi5fnZxevdUyZJkk
u+oncHvVkHauOWvZAQ+Waus0ndFJo9Llb1C00a/ABpCpReE3W1UM+8iiMyJ363VUPIeokh/8XckU
4UJCsKqlLA==