Future of FLOSS password storages: combined solution soon?

In a recent discussion about the future of KDE’s password manager KWalletManager it was mentioned that it is currently discussed to share a common password manager across all important FLOSS projects. While there is no result yet this is indeed a promising – and necessary – development.

It started with a question by Michael on the list kde-core-devel regarding the possibility to switch KWalletManager’s backend to the Qt Cryptographic Architecture (QCA) entirely. Robert answered that there was indeed discussion going on during FOSSCamp to merge all existing solutions (KDE, GNOME, OpenOffice, Firefox) to make it easier for the user to use these applications, but also to have the ability to sing-sign-on (meaning one login as user, and than automatically login everywhere else), which is a need for modern desktops. Afaik Fedora also has this topic on its radar, and it would surprise me if no one at OpenSuse, which constantly tries to bring these two desktops closer, has already put some thought into that.

While there are no visible results currently the need for such a solution is definitely present: At the moment it can happen that there are multiple programs used to store different keys in one single user session: Firefox on KDE introduces for example a second key storage right besides KWalletManager. Since the Open Source world does not want to force any solution on anyone, it should be possible to switch between Konqueror and Firefox without the need to take care of your passwords.
Technically there is no reason against a shared password storage, but it might tricky to convince the application/desktop developers. On the other hand, if KDE would get a pluggable KWalletManager backend it could even become possible to use the native key storages on other platforms if such APIs exist.

Short Tip: Move an X window in Linux with the Alt key

Usually an X window is moved under Linux via a click on the tile bar (and a following drag&drop). However, sometimes there are over-sized configuration dialogs or some strange behaviours of windows which move the title bar out of the screen. At that moment the window cannot be moved anymore via the window bar because it is not reachable.

But there is an easy way in Linux (and I wish Windows would have the same!) to move X windows regardless of the window title bar: by pressing and holding the Alt key any window can be moved with the left mouse button. This works under KDE as well as under Gnome.

Everyone who used Linux for a longer time knows that simple shortcut – but maybe there are some new users who don’t know it, and this post is for them.

Arora, a WebKit browser in Qt

The release of Qt 4.4 came along with the WebKit browser engine which could be tested with an included demo browser. This demo browser is now developed independent under the name Arora and is already, while in early development a cross platform Qt browser.

WebKit is a browser engine which was originally forked from KHTML and is now developed further by Apple, Nokia, Adobe, Trolltech and others. Up to a certain point there is also cooperation going on between KHTML and WebKit.

With Qt 4.4 WebKit is officially part of Qt, and therefore every Qt app can take advantage of WebKit (this is also true for every KDE app, but they can use KHTML for quite some time now anyway). The demo browser of Qt 4.4 was shipped with the release to show what the engine is actually capable off. Since it was already a (basically) working browser its own code repository under the name Arora. The WebKit code used is the one of Qt which is directly developd in the WebKit trunk.

The browser is currently under heavy development and is still in an early phase, so it can hardly be compared against the “old” ones like Firefox or Konqueror/KHTML. However, the browser already has a nicely working Rich Text Editor support which for example works with WordPress blogs:

Also, there special private browsing mode which makes it possible to deactivate the history and cookies just for a short time:

Besides, recently the support for flash plugins was included, and Arora can restore closed tabs. Currently planned features include the support for password store mechanisms in the form of plugins which will make it possible to connect Arora to kwalletmanager and therefore integrate it seamless with KDE – or to connect it with the Gnome keyring and integrate it with Gnome.

But it can also be seen that Arora is still in development: in the version tested on this machine there were some issues with the scroll bar and also with the line-edit field and the buttons on the Google home page:

Additionally, there are some things missing: especially web shortcuts which I really got used to should be added at some point in the future. Also, the preferences dialog does not list options which are normal for other browsers (always display tabs, always open in a new tab, etc.).

However, given that the development continues at the current speed these features should be available soon. In the long term Arora could become a real competitor to Firefox: while it is also cross platform like Firefox it could actually adapt the native design of each platform thanks to Qt. Additionally, with intelligent chosen plugins it should be easy to integrate it into the platform (password storage, favourites, desktop search, etc.). Last but not least thanks to its origins it features a much smaller memory foot print and is simply faster than Firefox.

For KDE users it could be an interesting alternative to Konqueror to have a look at WebKit and simply as a stand alone browser inside KDE.

In case you want to give Arora a first test the easiest is to run Ubuntu (probably in a virtual machine) and install the precompiled binary. Since Arora does require quite recent Qt packages it can’t be compiled in Fedora 8, and even Fedora 9 might not be sufficient at the moment.

Using Dell’s D/Dock docking station with Linux

Dell is shipping docking stations for it’s Latitude Laptops. I’ve tested a D/Dock and it does work with Linux. The only real problems have their roots in Linux’ shortcomings.

My new laptop has docking station support, and since these docking stations can be bought second hand at very reasonable prices I got myself a D/Dock.

It worked out of the box: the laptop, plugged to the docking station, just works. External devices connected via USB or the external monitor also work as they would be plugged directly to the laptop. I didn’t test the media bay, the DVI connector or the additional PCI slot, so I’m not sure if they would work. However, since there were no other problems I would at least be confident in trying these.

Hotplugging is also not an issue: the laptop can be plugged on or off the docking station while it is running. Of course, mounted USB devices connected to the docking stations should be unmounted before plugging off! But besides that there are no real problems.

The only real disadvantages of the docking station itself I was so far able to recognize are that it has too few USB ports and that it is a bit noisier than I would have expected.
There are just 3 USB slots at the back plus one at the side (which is a bit extended to work with Dell stuff, but still works as a normal USB slot), but I would have preferred to have at least 6. Mouse, keyboard, external hard disk, webcam, USB stick and a MP3 player are not uncommon devices these days.
The other problem is the noise of the docking station fan: while it is not really disturbing and far away from the fan of my former laptop it is at least noisier than the laptop’s fan. But since the docking station was quite cheap I might open it to check if I can do anything about it.

So basically everything works very well – however, there is one problem due to the shortcoming of Linux – or X to be more specific – itself: the external monitor is not detected and activated automatically. And the other way around, if the external monitor is activated alone and the laptop is unplugged, the laptop screen stays blank and there is no way to bring it back.
So the actual shortcoming is that, while the basic hotplugging support is available, there is too little automation there: X should make clear that at least one connected output device is active all the time! Also, there should be easy ways to define specific situations: if monitor xyz is connected, switch to xyz only, if monitor abc is connected, switch to abc and laptop monitor. The first one would be the external monitor of the docking station, the second one could be a projector.

But again, this is a problem due to Linux, not due to the docking station. I guess this will have to wait until the proprietary drivers deliver XRandR 1.2 support and until the distributions ship XRandR 1.2 GUIs at a larger scale and really implement these into the system. Fedora 9 will ship with a Gnome interface, and afaik KDE 4 has basic XRandR 1.2 support anyway. Still, I’m not aware of any demon like capabilities to enable automatic device selection as mentioned above…

Howto: Test the WebKit engine in Fedora

The Fedora repository contains a set of WebKit packages. Once installed they can give a first impression of WebKit’s abilities.

WebKit is a browser engine which was once forked from KHTML by Apple. Nowadays it is developed by the WebKit project where Apple still has quite some weight, but others are in the boat as well: Trolltech, Nokia, Adobe, some KDE developers, some GNOME developers, etc. Besides, WebKit will be part of the upcoming Qt 4.4, will play an important role in KDE’s Plasma and can also be used as a backend in GNOME’s Epiphany browser.

However, at the moment most of these developments are not here yet. But Fedora’s WebKit packages come along with basic WebKit browsers which can be used to test some websites against WebKit:

# rpm -qa|grep -i webkit
WebKit-doc-1.0.0-0.3.svn28482.fc8
WebKit-gtk-devel-1.0.0-0.3.svn28482.fc8
WebKit-qt-devel-1.0.0-0.3.svn28482.fc8
WebKit-qt-1.0.0-0.3.svn28482.fc8
WebKit-gtk-1.0.0-0.3.svn28482.fc8

# rpm -ql WebKit-qt
/usr/lib/libQtWebKit.so.1
/usr/lib/libQtWebKit.so.1.0
/usr/lib/libQtWebKit.so.1.0.0
/usr/libexec/WebKit
/usr/libexec/WebKit/QtLauncher

# ls /usr/libexec/WebKit/
DumpRenderTree  GtkLauncher  QtLauncher

The two executables QtLauncher and GtkLauncher are a simple browser based on Qt or Gtk, respectively. Since the path is usually not part of PATH the browsers must be started from the command line with the full path, /usr/libexec/WebKit/QtLauncher for example. After you’ve called that line via ALT+F2 the browser comes up.

But don’t expect too much: these are just basic browsers to show off the capabilities of the WebKit engine – nothing more. They are definitely not ready for production use – or any real use at all. The Qt version does not know how to handle addresses without the http://, usual shortcuts like Ctrl+L are not working, and plugins are not embedded at all. However, the Qt launcher has a nice effect of showing a link address when you hover over a link. The Gtk launcher is in a bit better shape: it does at least understand addresses, but than again it does not fill in the http:// after loading the page.

But nevertheless these two launchers can give you a first impression how this web engine works on a web page – in case you are a web developer this might come in handy. Also, if you are up for tests, you can check the current state of WebKit in regards to the Acid3-Test. Also, the first impression of the engine is rather nice: it seems to be rather quick and layouts web pages just nice. I’m looking forward to see new browsers based on WebKit.