Posted on

Where are my systray icons?

One of the features no longer available in the upcoming Plasma 5 release is the xembed based system tray (for explanation see my previous blog post). This can result in some applications missing a system tray icon, but it shouldn’t happen. There are patches around for various toolkits which will turn the xembed icon into a status notifier item. Our KDE packagers were informed back in March about the upcoming change and which patches should be applied to which components.

In summary that is for the toolkits:

  • GTK2: needs libappindicator1 and all packages having an optional
    dependency to it should get compiled with it.
  • GTK3: needs libappindicator3-1 and all packages having an optional
    dependency to it should get compiled with it.
  • Qt4: needs sni-qt and a patch to Qt 4.8
  • Qt5: Won’t need adjustments starting with Qt 5.4, but with Qt 5.3 this commit should be cherry-picked.

Note for Skype users: Skype does not provide a 64 bit package, because of that one also needs the sni-qt package in the 32 bit variant.

For GTK there is also a new library to implement status notifiers available, for more information read Marco’s blog post on the topic.

Unfortunately not all distributions have included the patches yet. If for one of your applications the system tray icon is not available although it works on other distributions I recommend to create a bug report in your distribution against the affected package to show that these additional build dependencies are required.

In the worst case you could install a third-party dedicated xembed system tray application. An example is “wmsystemtray”, this one can start with:

wmsystemtray --non-wmaker --bgcolor white

and best also configure a KWin window rule to have it without decorations and on all desktops:

Description=Application settings for wmsystemtray
desktop=-1
desktoprule=2
noborder=true
noborderrule=2
skippager=true
skippagerrule=2
skipswitcher=true
skipswitcherrule=2
skiptaskbar=true
skiptaskbarrule=2
type=2
typerule=2
wmclass=wmsystemtray0 wmsystemtray
wmclasscomplete=true
wmclassmatch=1
Posted on

KWin is no more

Now that I have your attention: the binary of KWin/5 just got renamed from “kwin” to “kwin_x11”. For you as a user nothing changes, the startup is adjusted to start kwin_x11 instead of kwin. Nothing else changed. The D-Bus interface is still org.kde.KWin, the config file is still “kwinrc”, etc. etc. Only if you start KWin manually remember to run “kwin_x11 –replace &” instead of “kwin –replace &”.

Say thanks to Hrvoje Senjan for preparing the patches to rename the binary and adjust all the places where the binary name is used.

Posted on

DBus Activation for apps in prefix

On my systems I noticed that some services like kglobalaccel are not automatically started when logging into the system. This is on the one hand rather annoying on the other it could indicate a bug in our setup. So this morning I started to look into the issue with kglobalaccel.

Kglobalaccel is a service which is supposed to get started through dbus. My installation prefix is “/opt/kf5” and so the service file gets installed to “/opt/kf5/share/dbus-1/services/org.kde.kglobalaccel.service” – that looks fine. After some investigation I figured out that dbus-daemon looks in $XDG_DATA_DIRS as a search path. Our startkde script adjusts $XDG_DATA_DIRS to include /opt/kf5/share before launching the dbus daemon. But when looking at the environment of the running dbus-daemon one could see the problem: it doesn’t use the set environment variable. The reason is obvious: dbus is nowadays started before the desktop environment gets started.

This means D-Bus doesn’t know where to look for the service files. To fix this create a file “/etc/dbus-1/session.d/plasma-next.conf” with the following content (adjust path as needed):

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
  <servicedir>/opt/kf5/share/dbus-1/services/</servicedir>
</busconfig>

Save, logout, login and kglobalaccel and others should auto start.

Posted on

How to test and fix translations for frameworks 5 applications

With frameworks 5 the translation system changed quite a bit resulting in your application not being translated without any adjustments. In this blog post I want to highlight how you can test whether your application loads the translation correctly and how to fix it if not. First of all I recommend to read the general translation documentation for the KI18n framework.

Like with kdelibs4 there is a test language which wraps every translated string “foo” to “xxfooxx”. This language needs to get installed. For that follow the following steps:

mkdir i18n # create a directory for the checkout
cd i18n # change into it
svn co svn://anonsvn.kde.org/home/kde/trunk/l10n-kf5/scripts # check out scripts
svn co svn://anonsvn.kde.org/home/kde/trunk/l10n-kf5/x-test  # check out test language
./scripts/autogen.sh x-test # generate build system for test language
mkdir x-test-build # create build dir for test language
cd x-test-build # and change into it
cmake -DCMAKE_INSTALL_PREFIX=/opt/kf5/ ../x-test # adjust /opt/kf5/ to your kf5 install dir
make
make install

With these steps the language gets installed. Now you can run your application to test with the LANGUAGE environment variable. For this blog post I use kinfocenter as the test application:

LANGUAGE=x-test kinfocenter

As you can see kinfocenter is not yet translated properly:

Aus i18n-kf5

The first step is now to connect the application to the catalog. The catalog is the name of the .pot file in Messages.sh – in the case of our test application that is “kinfocenter”.

This is being done with the following call:

KLocalizedString::setApplicationDomain("kinfocenter");

This has to be done before calling any i18n call, so most likely it is in your main function and before the construction of QApplication. After doing this change our kinfocenter looks like that:

Aus i18n-kf5

That’s better but there is still a lot of untranslated code around. The reason for that is kinfocenter loads libraries to display the content and those libraries are not yet connected to the catalogs. In kdelibs4 time one did that through the insertCatalog function, now it needs to be done in the library.

The way is to add a definition for TRANSLATION_DOMAIN with the catalog as value in the CMakeLists.txt of the library. So for the info module in kinfocenter that’s:

# KI18N Translation Domain for this library
add_definitions(-DTRANSLATION_DOMAIN=\"kcm_infosummary\")

And now our kinfocenter looks like that:

Aus i18n-kf5

Of course one needs to do these adjustments for each of the libraries.

Last but not least one needs to mention ui files. For those one needs to use ki18n_wrap_ui in the CMakeLists.txt.