D-Bus Sightseeing

I figured it was time to learn more about D-Bus. Today, let me share some useful calls that I found so far. Hopefully they will inspire you to experimenting too and together we will have a chance of learning more.

$ dbus-send --print-reply \
    --dest=org.kde.klipper \
    /klipper \
    org.kde.klipper.klipper.getClipboardContents
method return sender=:1.37 -> dest=:1.73 reply_serial=2
string "Hello D-Bus"

Your result will be probably different. In fact, I spent several minutes wondering why the method does not return anything and just repeats its name ;-)
The meaning of the parameters: --dest is the destination connection; apparently D-Bus cannot find it out from the following parameter: /klipper: the destination object. org.kde.klipper.klipper is the interface. Most objects have their own interface plus the introspection interface org.freedesktop.DBus.Introspectable. getClipboardContents is of course the method name.

For further exploration, the GUI tool qdbusviewer is very useful. Try it for calling getClipboardContents now.

$ dbus-send --type=method_call --dest=org.kde.kwin \
 /KWin org.kde.KWin.nextDesktop
$ dbus-send --type=method_call --dest=org.kde.kwin \
 /KWin org.kde.KWin.previousDesktop
$ dbus-send --type=method_call --dest=org.kde.plasma \
 /App org.kde.plasma.App.toggleDashboard

The type option is necessary because dbus-call defaults to type=signal which would not work. (BTW does anyone have a nice example for demonstrating a signal?) With print-reply in the first example, type=method_call is implied.

Let's pass some arguments:

$ dbus-send --type=method_call --dest=org.kde.klipper \
 /klipper org.kde.klipper.klipper.setClipboardContents \
 string:'Test Beta2!'
$ dbus-send --type=method_call --dest=org.kde.krunner \
 /Interface org.kde.krunner.Interface.display \
 string:'system'

So far we have been using the session bus. The system-wide bus offers even more fun:

$ dbus-send --system --print-reply \
 --dest=org.freedesktop.NetworkManagerSystemSettings \
 /org/freedesktop/NetworkManagerSettings \
 org.freedesktop.NetworkManagerSettings.ListConnections

array [
   object path "/org/freedesktop/NetworkManagerSettings/0"
   object path "/org/freedesktop/NetworkManagerSettings/1"
   object path "/org/freedesktop/NetworkManagerSettings/2"
]

$ dbus-send --system --print-reply \
 --dest=org.freedesktop.NetworkManagerSystemSettings \
 /org/freedesktop/NetworkManagerSettings/1 \
 org.freedesktop.NetworkManagerSettings.Connection.GetSettings

 array [
    dict entry(
       string "802-11-wireless"
       array [
          dict entry(
             string "ssid"
             variant                   array [
                   byte 102
                   byte 114
                   byte 111
                   byte 103
                   byte 115
                ]
          )
          dict entry(
             string "security"
             variant                   string "802-11-wireless-security"
          )
       ]
    )
 /* more data. BTW you can't see any of this in qdbusviewer. */
 ]

(Interesting, every even call to NMS fails with a timeout)

Finally, a long list to scroll up while the music plays:

$ dbus-send --system --print-reply \
 --dest=org.freedesktop.Hal \
 /org/freedesktop/Hal/Manager \
 org.freedesktop.Hal.Manager.GetAllDevices

TWM tip

TWM is the ancient window manager that you can use when troubleshooting the problems with X. It has always annoyed me that it can't make up its own mind and you have to place the windows manually when they first appear.

Solution:

cp /usr/share/X11/twm/system.twmrc ~
echo RandomPlacement >> ~/.twmrc

TODO: make it the default in openSUSE.

openSUSE 11.0 Beta 1: Is that the murderer's name and address in the victim's hand?

As Beta 1 is getting mirrored, I am excited to tell you about obscure parts of the installation that I hope you will never see.

YaST does not crash. Never. Well, only rarely. Especially not during the initial installation. Seldom. So what do we do when it does? We want the backtrace and the debugging logs. So before 11.0 we would ask you to please let it crash again, but with some special options to produce the backtrace and the debugging info. Spoils the fun.

Since Alpha 2 YaST will take care of the backtrace. Since Beta 1, it will also produce tons of the debugging messages, but throw most of them away and only show the last few of them in case of a crash. Reporting a bug has become much easier!

This has actually helped us already in debugging one crash that blocked the release of Beta 1, bug 380283. If you want to see for yourself, search the log for "got signal". The next line says "Liberating suppressed debugging messages" and afterwards there is "Back trace".

References: FATE#302167, FATE#302166.

iogrind in openSUSE Build Service

iogrind is Michael Meeks' I/O profiler and visualizer. I wanted to see if it can help me with improving YaST performance, and I was surprised to find that there are no RPMs.

Well now there are: iogrind in openSUSE Build Service. The packaging is very crude for now, but it appears to work. Now I have to make some sense of the tool :-)

kezboard.rpm - Adapts zour QWERTY habits to a QWERTZ world

$ yzpper info kezboard
* ...
* Reading installed packages [100%]

Information for package kezboard:

Repository:
Name: kezboard
Version: 1.0-1
Arch: noarch
Installed: Yes
Status: up-to-date
Installed Size: 0 B
Summary: Adapts zour QWERTY habits to a QWERTZ world
Description:

Do zou keep tzping loadkeys instead of loadkezs and zypper instead of yzpper?
Then this package could help zou.

Authors:
--------
    Martin Vidner 
$ rpm -ql kezboard
/bin/gunyip
/bin/gyip
/bin/loadkezs
/bin/sznc
/bin/ycat
/usr/bin/byip2
/usr/bin/compiy
/usr/bin/pzthon
/usr/bin/rubz
/usr/bin/unyip
/usr/bin/yip
/usr/bin/yzpper

Get kezboard as an RPM in the openSUSE Build Service.