PackageKit develops further

Richard Hughes’ PackageKit develops quite fast. He recently implemented support for system tray status warnings, information if reboots or log-outs are required, merged a conary backend, implemented network connection awareness and improved the GUI. While not every feature is supported in every backend this project really looks interesting and could in parts change the image the average user has about Linux.

The idea of PackageKit is to have a D-Bus abstraction for the various software management backends. This would solve a set of problems at once and would at the same time allow to develop simple, cross distribution GUIs for managing software installation and updates.

In the current state it now offers network connectivity awareness: with the help of NetworkManager it checks if there is a connection to the Internet and if it can actually download stuff. Also there are now status icons in case of updates and a system tray bubble in case of security sensitive updates. And if there is the need to reboot, re-login or restart a program PackageKit can tell.
However, in such cases the backend must tell PackageKit what is a security update and what not, and when something has to be rebooted and when not. So these features depend on the backends. In case of yum at least it will work:

yum doesn’t know the different between security/other updates for Fedora […] the next production update will start generating this

Looks like we will have that support in Fedora 8.

Speaking about backends, there is already a conary backend which was merged into the development tree. And it basically works. Nice to see that that also “smaller” distributions start picking up the idea. I wonder how long it will take to see others like Novell/Suse or Mandriva to take up this project to develop their own backend. That would be huge step in the right direction.

I also wonder when there will be the first KDE frontend for PackageKit. Yesterday Richard Hughes mentioned that he split out the Gnome bits so that libpackagekit now only depends on glib, libnm, dbus-glib and policykit. It should be possible by now to develop a KDE frontend. Also, since everything works over D-Bus it should be possible to connect to D-Bus directly, however the D-Bus API might not be finalized yet and might change.

As a side note: PackageKit depends on a set of fairly new technologies. NetworkManager wasn’t even enabled by default in Fedora 7, and policykit will have its first appearance in Fedora 8. If PackageKit really spreads around the distributions it is likely to take the other technologies with it (I have no doubts about NetworkManager, but wonder how policykit will do).

RandR and TV-Out support merged into free ATI driver, AMD has nothing comparable

airlied posted a note that the RandR 1.2 branch of the free ATI driver was merged into master. This means that the next release of the ATI driver might already be RandR 1.2 capable release.

Recently the RandR 1.2 branch of the free X.Org ATI driver got quite some attention: besides the already working RandR 1.2 implementation the driver also got (beta) TV-Out support.
In the meantime the main development tree, 6.7, didn’t get that much love and therefore the developers decided to merge the RandR 1.2 tree into master and ditch 6.7:

really the 6.7 tree isn’t getting much developer loving, so I’ve branched ati-6.7-branch off and merged the randr-1.2 love into master

This means that the next release is likely to already have RandR 1.2 and TV-Out support. That wasn’t planned originally, but I like it!

This development however sheds some pretty bad light onto AMD/ATI: while there have been big promises in the past regarding a completely and totally new driver there have been only disappointments in the last releases. In fact, wrt features the free driver has much more to offer at the moment than the solution offered by AMD/ATI. The only advantage of the proprietary driver is its performance – but even in that regard it is hardly comparable to the performance of the Windows drivers. If you’d like to be mean you might say: they can not even do a proper job although they have the hardware specs.

And slowly I do wonder how AMD/ATI is going to make good the damage – they would have to release a driver which at least supports AIGLX and maybe also TV-Out. I would need to see RandR 1.2 support as well (like it is planned for the proprietary NVIDIA drivers) to like AMD/ATI again.

lineak: Using multimedia keyboards with Linux

I recently got a new “multimedia” keyboard which comes along with a set of extra keys. While my keyboard needed some initial manual configuration it works now almost without problems using Lineak.

Lineak is a tool which aims at easy set up and configuration of multimedia keys on modern keyboards: these keyboards have additional keys which are usually not supported by Gnome or KDE since they are outside the usual keymaps. But lineak can handle such keys and can bind them to specific functions and actions.

In my case I got a Benq X-Touch 122 which I used with my Fedora machine. Since Lineak is part of the standard Fedora repository the installation was pretty easy: yum install lineak*. The asterisk makes sure you get additional plugins, more about that later. After the installation the command lineakd -l shows you a list of supported keyboards. If your keyboard is among them you’re lucky, if not you have to do some manual tuning. Basically you start xev, catch all the keyboard mappings and afterwards add a new section in /etc/lineakkb.def/. Have a look at the other entries of your hardware vendor and you should get the idea.
My keyboard wasn’t supported so I added the following table:

[BENQ-X122]
brandname= "BenQ"
modelname ="X-Touch 122"
[KEYS]
Standby = 223
Back = 234
Forward = 233
Home = 130
Mail = 236
Favourite = 230
[END KEYS]
[END BENQ-X122]


Everything works now, except for the so called function “Function” key which gives access to alternative functions on the F keys. Nice.
The nast step is to make sure that lineak starts everytime you boot up your system – this is done for example by placing something in $HOME/.kde/Autostart/, for example a file like this:

[Desktop Entry]
Type=Application
Exec=/usr/bin/lineakd &
Icon=
Comment=LinEAK - Daemon
Comment[de]=LinEAK - Daemon
Terminal=0
Name=lineakd
Name[de]=lineakd

Now the keyboard special keys can be configured in $HOME/.lineak/lineakd.conf:

Back = AMAROK_BACK
Favourite = KMIX_MUTE
Forward = AMAROK_FORWARD
Home = kfmclient openProfile webbrowsing
Mail = KMAIL_COMPOSE
Standby =

Most stuff should be self-explanatory, for the plugins you can read the docs at /usr/share/doc/lineak-*plugin*/README. There are also some GUI configuration tools out there, but at least the KDE tool had a segfault here

However, despite how nice lineak really is, there are problems regarding the future of the tool: I thought that the best would be to add my keyboard table to the lineak information and therefore sent them in. However the answer was a bit sad:

I got it, but I no longer have time to work on lineak. Since another maintainer has not stepped up to the plate, unfortunately these submissions will not get included in the distribution.

This means that lineak is not developed anymore and that it is unlikely to see any larger improvements there in the future. It also means that the keyboard table wont be updated and that everyone with an unsupported keyboard needs to keep these information somewhere in case of updates or re-installs.

Maybe it is time to integrate such a function into X itself to make sure that its development continues. But on the other hand I would also like to see them well integrated with KDE and Gnome and maybe even able to download new keyboard sets via gethotnewstuff. But at the moment the future of multimedia keyboards is rather murky.

Thanks to for a post about lineak which got me started and where I took the autostart entry from.

KDE config to get a SQL backend

Mickael Marchand created a branch in KDE SVN to work on a KDE configuration storage system based SQL. This picks up the idea to have more ways in KDE to store the configuration than just having the file based way.

This idea to improve the current, INI-like file based storage system of KDE’s configurations was first made public by Aaron Seigo in January 2006. He suggested to use for a ldb which was/is used for Samba 4:

kde could get a centralizable, replicatable, scalable, fast and safe config storage system that can move us beyond ini-style configs without much work on our part. being able to store data in binary formats also means that we may find we get some performance boosts from not having to ascii-ize everything on the way out to the config file and repeat the process in reverse when reading it in.

As he later also made clear the idea was not to simply replace the current backend, but to write another one, to make them replaceable. And since kconfig was designed from the start as an API for different backends this idea was indeed quite realistic.

But nothing happened over the time until last Commit Digest’s Issue 72. There it was mentioned that Mickael started to work on a SQL backend:

API change in kconfig really basic SQL backend […]
and, the SQL backend, just a basic sqlite one for now (not even checking for locks/nb of connexions/… etc)

till now, I was able to get kconfigtest to success all tests with the DB backend, and was able to run kwrite, modifying options etc

Besides a maybe faster configuration backend this work will truly abstract the configuration system and will make it possible to write others. So if you want to configure KDE in future with configuration system xyz – just write a backend for it. Think of possibilities like Elektra.

KDE 4: cursor themes, LinuxMCE, some impressions

Current KDE 4 SVN has an improvement that makes it possible to change the cursor theme without re-starting X. Also, the LinuxMCE team now officially cooperates with KDE to merge technology where it makes sense. I also took some general KDE 4 screenshots to gather some impressions.

Cursor themes

One of the worst experiences I ever had when I showed an interested friend Linux for the first time was that changing the cursor theme (in KDE) made it necessary to restart X. This is something I didn’t forget

While I’m not sure how the situation is in Gnome (comments appreciated) this problem will be solved with KDE 4 as Commit Digest Issue 71 says:

Fredrik Höglund committed changes in /trunk/KDE/kdebase/workspace/kcontrol/input:
Make it possible to switch cursor themes without having to restart KDE.

Good to see that!

LinuxMCE and KDE 4

It was announced these days that LinuxMCE and KDE team up to improve the LinuxMCE UI and the general user experience. While LunuxMCE comes atm with its own full screen UI and therefore does not really need any specific kind of underlying desktop environment LinuxMCE already built upon KDE because:

in LinuxMCE 1.0, Ubuntu and LinuxMCE ran in separate X-sessions, so LinuxMCE could have its own desktop and window manager. However, you cannot have two X sessions both using hardware acceleration, therefore LinuxMCE forced Ubuntu to use Vesa mode, and the integration was messy. KDE, however, does allow use of XFWM, which supports compositing and all the other visual goodies, so now LinuxMCE runs entirely within the KDE desktop

For the future both teams now decided to team up for better cooperation. According to the announcement LinuxMCE’s interface will use Plasma in the future to make it easier to create new UI’s and also to integrate it seamlessly with the underlying KDE. If that works out the LinuxMCE developers will be able to concentrate on the UI design and the media center basics without the need to develop their own UI framework – the Plasma team could take care of it automatically by improving Plasma itself.

However, there will not be a KDE 4 integrated version of LinuxMCE before KDE 4.1 because at the moment there is mainly the announcement, and quite a lot of work has to be done until there is a Plasma integrated LinuxMCE.

Some impressions

After I rebuild the newest KDE SVN yesterday I took some screenshots to collect some impressions. Nothing changed that much over the last few weeks (most work is done now in Bug fixing) so these shots are nothing really new.

First of all the new Font installer already announced in Commit Digest Issue 69:

Second, there is an impression of the re-worked konsole with a configuration display. At the bottom you see the improved tab interface. The configuration dialog shows the colour choose. Interesting in this regard is that the konsole window switches to the new colour the moment you move your mouse over the new colour. The preview is fast and slick and a nice way to quickly see how the new colours will match (or not).

The next screenshot shows the Phonon configuration window. On the left side you see the major audio task while the right side lists the interfaces. In that way a user can assign another interface for each task. This makes sure that you can use your headphone for your VoIP while the music play back on your sound card which is connected to your speakers. Quite useful especially if you have a headphone with integrated soundcard.

/p>

Last but not least one of the “new” user applications of KDE 4: Gwenview, the default image viewer of KDE 4. While the crop tool window is a bit strange (the floating window should be somewhere at the side, not in the middle, because most average users will not use it but the crop field in the picture itself. But besides that the interface is slick and nice.

In general KDE 4 looks nice – but there are still tons of bugs. Konqueror crashes, Dolphin is easily to crash, the Oxygen theme still seems to have quite some problems (check the file operations in the Gwenview shot), the systemsettings are far from complete, and so on. And of course the kicker replacement is not there yet (but I have no doubt that it will be there in time).
KDE 4 is on a very good way, and pretty far already – but it is simply not there yet, and Beta sometimes seems to be a bit too optimistic. But on the other hand it is just a question of time until it will be stable!