Starting KF5 using the I3 window manager

Lately I started experimenting several tiling window managers, and I settled on I3 (see its Official site and the corresponding ArchLinux wiki page)

I now plan to return hacking KF5 and I’d like to use this tiling manager. In KDE4 I simply used the “Default Applications” control module from “System Settings” to choose i3, after adding the right i3.desktop file. However, with KF5 that will not be enough. For some reason kwin will still be loaded. (And BTW, the new kwin looks really great. I also like the new plasma desktop very much, but it won’t fit my workflow, as I prefer tiling WMs paradigm) Today I started searching a quick way to workaround that and here it is what I did.

Firstly, create the $KF5/share/ksmserver/windowmanagers/i3.desktop file with this contents:

[Desktop Entry]
Encoding=UTF-8
Name=i3
Comment=Highly configurable framework window manager
Type=Application
Exec=i3
TryExec=i3

Then edit the file ~/.config/ksmserverrc and modify the windowManager line from the [General] section:

[General]
# other lines ommited
windowManager=i3

Alternatively, you can use the “Default Applications” control module from KF5 System Settings to change the window manager to i3.

Finally, here is the little bit that made it. Modify the KF5 startup script to define the KDEWM environment variable. It should read like this:
export KDEWM=/usr/bin/i3

Here is how:
On my system, I’m using kdm. For it to start a KF5 session, I created /usr/share/config/kdm/sessions/kf5.desktop with this contents:

[Desktop Entry]
Encoding=UTF-8
Type=XSession
Exec=/home/kde5/start-kf5
TryExec=/home/kde5/start-kf5
DesktopNames=KF5
Name=KF5

As you can see, my KF5 is installed in /home/kde5 (others may have it in /opt/kf5). The start-up script, named ‘start-kde’ simply sets the righ environment variables, calls ssh-agent and gpg-agent, then calls startkde from KF5. I added the export KDEWM=/usr/bin/i3 line into this script.

Quit your current session, choose the KF5 session in KDM and enjoy I3 with KF5!

I’ll now return to tinkering it, as some adjustments still need to be done 🙂

New GnuPG backend for the KDE Wallet!

The classical KDE Wallet uses blowfish algorithm to encrypt sensitive data before writing it to disk. The key used for the encryption is a user-defined password that sometimes is even left empty by the user!

GnuPG offers some very strong encryption algorithms and uses passphrase-protected long keys. But I’m not going to talk about GPG here. I’ll rather tell you that I just added a new backend in kwalletd allowing for GPG-encrypted wallets! The code is fully functional and I actually configured my KDE session to use it! So here are the screenshots.

gpg-kwalletmanager

gpg-kdewallet-system-settings

As you can see, I now have a “testgpg” wallet that is selected as the system-default wallet. So what, you’d say? Well, I’d answer, as you can see there’s no apparent difference when using these wallets, and that’s expected behavior. Things changes however when you try to create a new wallet. There are two ways to do that. The usual way is in system settings, where user would click the “New…” button you see in the second screenshot. That will pop-up a wizard that I adjusted to let the user choose between the more secure GPG-backend or the classical, blowfish-based, backend.

After clicking “New…”, user is prompted for the new wallet’s name, as usual, then here is the redesigned “new wallet wizard”:

disclaimer: I’m not an english-native, so wording may not be the best in the following screenshots. Feel free to adjust the strings in the sources 😉

gpg-kwalletwizard1

gpg-kwalletwizard2

gpg-kwalletwizard3

The screenshots above show the case where an encryption capable GPG key was found on the system. If the user do not have such a key, then the last page changes to this:

gpg-kwalletwizard3

(the different color comes from the different color-scheme my test user has in it’s kde session)

And that’s all it takes!

If using KWalletManager, the wizard is slightly different (I don’t know why kwalletd uses two code paths for wallet creation, but I choose to keep this original behavior):

  • Choose “File > New wallet…”
  • Enter the new wallet’s name
  • Next, the following wizard will show:

gpg-newwallet1

gpg-newwallet2

That’s it for this case too!

kwalletd will use GPG when storing wallets and when opening them. The same KDE session can handle simultaneously both file formats. kwalletd will transparently detect the file format and load the correct backend to handle it. So you can do as I did:

  • Create a new GPG-based wallet (using one of the previous described methods)
  • Fire KWalletManager and
    • Select your old wallet then choose “File > Export as XML…” to create an XML file with your sensitive data
    • Select the GPG-based wallet then choose “File > Import XML…”, then choose the file you just saved
    • NOTE: “File > Import wallet…” should also work, but in that case you should choose the .kwl file corresponding to your old wallet, located in ~/.kde/share/apps/kwallet
  • Go to System Settings > Account Details > KDE Wallet and select the newly created, GPG-based, wallet from the “select wallet to use as default” combo box
  • gpg-encrypt the XML file to keep a back-up

What about file sizes? Well, on my system, the new GPG-based wallet show a dramatic drop in file size for storing the exact same data:

/home/valentin/.kde/share/apps/kwallet
$ ll
total 80
-rw------- 1 valentin valentin 60664 Aug 15 16:54 kdewallet.kwl
-rw------- 1 valentin valentin 19329 Aug 15 18:56 testgpg.kwl

The performance difference is not noticeable. There’s only a slight lag on first GPG library initialization.

IMPORTANT NOTE: the passphrase dialog only shows once. Even if the wallet is closed after initial open, subsequent opening will occur silently during the same KDE session! That’s great news for those annoyed by the kwallet password prompt in the middle of the KDE session.

Eager to test the code? I’d be glad to hear your feedback, as this code should be thoroughly tested and reviewed before letting it go to master. I’ll soon post a review-request on the official mailing list. The code is available under the kde-runtime’s branch named kwalletd-gpg. The new features are compiled-in only if your system has QGpgme, part of kdepimlibs, which in turn requires gnupg and gpgme.

A final word: those of us who own a FSFE Fellowship Smart Card now have a new cool usage for it!

KMail, Akonadi and MariaDB on ArchLinux

ArchLinux recently switched to MariaDB. After the complete system update, followed by the usual full recompile of Qt4 and KDE4, my KMail2 setup became unstable. While reading mails was still possible, I experienced lags when switching from one folder to another (“please wait while retrieving message contents”) and, more problematic, sending mails worked very randomly.  I used the akonadi server configuration tool and it’s “test” feature to check my setup and then, surprise, I got errors with my database. OK, I thought, it’s time now to restart with a fresh home directory, as mine has several years, and configuration from previous setups was left, along my switch to ArchLinux then to custom compiled KDE4.

But with the new, fresh home directory, the “test” function still showed errors:

130605 0:10:50 InnoDB: The InnoDB memory heap is disabled
130605 0:10:50 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130605 0:10:50 InnoDB: Compressed tables use zlib 1.2.7
130605 0:10:50 InnoDB: Initializing buffer pool, size = 80.0M
130605 0:10:50 InnoDB: Completed initialization of buffer pool
130605 0:10:50 InnoDB: highest supported file format is Barracuda.
130605 0:10:50 InnoDB: Waiting for the background threads to start
130605 0:10:51 Percona XtraDB (http://www.percona.com) 5.5.30-MariaDB-30.1 started; log sequence number 2612486
130605 0:10:51 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them
130605 0:10:51 [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist
130605 0:10:51 [ERROR] Native table 'performance_schema'.'events_waits_current' has the wrong structure
130605 0:10:51 [ERROR] Native table 'performance_schema'.'events_waits_history' has the wrong structure
130605 0:10:51 [ERROR] Native table 'performance_schema'.'events_waits_history_long' has the wrong structure
130605 0:10:51 [ERROR] Native table 'performance_schema'.'setup_consumers' has the wrong structure
130605 0:10:51 [ERROR] Native table 'performance_schema'.'setup_instruments' has the wrong structure
130605 0:10:51 [ERROR] Native table 'performance_schema'.'setup_timers' has the wrong structure
130605 0:10:51 [ERROR] Native table 'performance_schema'.'performance_timers' has the wrong structure
130605 0:10:51 [ERROR] Native table 'performance_schema'.'threads' has the wrong structure
130605 0:10:51 [ERROR] Native table 'performance_schema'.'events_waits_summary_by_thread_by_event_name' has the wrong structure
130605 0:10:51 [ERROR] Native table 'performance_schema'.'events_waits_summary_by_instance' has the wrong structure
130605 0:10:51 [ERROR] Native table 'performance_schema'.'events_waits_summary_global_by_event_name' has the wrong structure
130605 0:10:51 [ERROR] Native table 'performance_schema'.'file_summary_by_event_name' has the wrong structure
130605 0:10:51 [ERROR] Native table 'performance_schema'.'file_summary_by_instance' has the wrong structure
130605 0:10:51 [ERROR] Native table 'performance_schema'.'mutex_instances' has the wrong structure
130605 0:10:51 [ERROR] Native table 'performance_schema'.'rwlock_instances' has the wrong structure
130605 0:10:51 [ERROR] Native table 'performance_schema'.'cond_instances' has the wrong structure
130605 0:10:51 [ERROR] Native table 'performance_schema'.'file_instances' has the wrong structure
130605 0:10:51 [Note] /usr/bin/mysqld: ready for connections.
Version: '5.5.30-MariaDB' socket: '/home/valentin/.local/share/akonadi/socket-zx.rusu.info/mysql.socket' port: 0 Source distribution

The problem was solved by switching to the external MySQL (more precisely, it’s MariaDB) server I happen to run on the same system. I created a new “akonadi” database, granted full rights to a dedicated “akonadi” user. I also cleared the “options” field, that for an obscure reason specifies a socket connection and now I’m back to a stable configuration after starting the akonadi server.

Oh, I also needed to do the following adjustments:

  • Remove then recreate the local folders, as my previous configuration stored mails in a KMail folder
    • In fact, KMail forced me to do that, as it crashed after the switch to the new database with these errors
kontact(17733)/libakonadi Akonadi::SpecialCollectionsRequestJob::slotResult: Failed SpecialCollectionsRequestJob::slotResult "Failed to fetch the resource collection." 
kontact(17733) MailCommon::Kernel::emergencyExit: "The Email program encountered a fatal error and will terminate now.
The error was:
Failed to fetch the resource collection."
  • Remove then recreate the “mail dispatcher agent” in akonadi console
  • Reconfigure the folders
    • Now, all my old messages are shown as unread, but that’s not really a problem
  • Reconfigure mail filters
    • That’s because removing the local folders left the rules without target folders
  • Reconfigure folder expiration rules

A final word about the performance of KMail. It seems to me that it’s now a lot more responsive. The application is now really fast displaying my mails, be it on my IMAP server or into the local folders. Congrats to the PIM team!

 

Facelifting KWalletManager

As I previously announced on G+, I started some ui refactoring of the KWalletManager tool from kdeutils. This triggered some very helpful comments and suggestions, discussed on the kde-core-devel mailing list. I now proudly announce that the code made it to the master branch, so next time you’ll compile kwallet you’ll get the new, face-lifted, KWalletManager!

Main features are:

  • Use only one main window, based on the KPageWidget
  • Search logic has been improved and now the first item that matches automatically get selected, to help reduce the click count
  • The wallet editor got a new tab that allow you see what applications are currently connected, manage these connections and the associated permissions

Many thanks to Aurélien Gateau for the new design sketches, Till Schäfer for some very helpful suggestions and all the others who discussed this on the mailing list.

Here are the screenshots:

kwalletmanager-walleteditor kwalletmanager-applications

 

Enjoy the new KWalletManager!

Bientôt une tablette entièrement basée sur Linux / Plasma KDE

L’un des principaux contributeurs de la communauté KDE, jusqu’ici sponsorisé par Nokia/Qt, vient d’annoncer une toute nouvelle tablette, basée sur GNU Linux et plus précisément sur le projet Mer, le successeur de Meego.

Un premier post présente le matériel, puis un deuxième post présente plus en détail la partie logicielle.

Ces deux annonces ont été précédés par 4 autres billets, dans une tentative de monter le suspense parmi ceux qui le suivent. Tout ça parce que nous assistons à un tournant dans la communauté Qt/KDE, depuis que Nokia a décidé de passer le flambeau de la maintenance de Qt à la communauté. Dans la foulée, Aaron a du se construire un nouveau départ et j’espère qu’il aura tout son succès. En tout cas, moi j’achèterai sa nouvelle tablette, quand elle sortira !

Posted in KDE

List DBus installed services

If, like me, you’re wondering if the shining new DBus service you written is correctly recognized by the DBus daemon, then issue this command:

> qdbus org.freedesktop.DBus / ListActivatableNames

You’ll get an output like this one:

org.freedesktop.DBus
org.freedesktop.Notifications
org.kde.fontinst
org.gnome.GConf
org.freedesktop.Akonadi.Control
org.gtk.vfs.Metadata
vandenoever.strigi
org.kde.kuiserver
org.gtk.Private.AfcVolumeMonitor
org.gnome.GnomeVFS.Daemon
org.kde.knotify
org.gtk.vfs.Daemon
org.freedesktop.xesam.searcher
org.openobex
org.freedesktop.secrets
org.gtk.Private.GduVolumeMonitor
org.gtk.Private.GPhoto2VolumeMonitor
ca.desrt.dconf
org.kde.krunner

All these names come from the .service files installed on your system and recognized by the dbus-daemon.

git cherry-pick : la cerise sur le gateau

Le nouveau système de gestion des versions créé par Linus n’a plus besoin d’être présenté. Il est très pratique et cela se voit dans sa vitesse d’adoption. Mais la petite commande “cherry-pick” me fait réagir. C’est trop pratique ! Elle permet de reporter un jeu de modifications d’une branche vers une autre sans passer par la case “checkout de la branche cible + fusion”. Cette commande est tellement puissante qu’il est plus long de la décrire que de la mettre à l’oeuvre. Voir l’article (en anglais) que j’ai écrit sur la techbase KDE.