Category Archives: GNOME

Plans for Gtk+/GNOME 3.0 surfaced

Tux
At the GNOME conference GUADEC plans were presented how the transition to the new Gtk and GNOME is supposed to happen. The basic idea is to make the transition as smooth as possible by first cleaning up everything and introducing new concepts later on.

The news flash came right from GUADEC today: there will be a GNOME 3.0, and it will break the libs. Most news sites picked that up, but unfortunately there are hardly any further information out there.
A notable exception is the Austrian derStandard.at which covered the topic with a bit more details.

Basically the main aim for Gtk+ 3.0 is to clean up everything. Old/Not anymore needed functions will be dropped. The current state of this cleaning is tracked at the GNOME wiki. New features are planned for versions coming afterwards. This will of course include ABI/API brakes, but an aim is to make such a transition smooth. Well, it would be surprising if it wouldn’t ;) One notable idea though is to flag all dropped functions as “deprecated” in an upcoming GTK+ 2.x release.

The GNOME release team also plans to drop unnecessary/old code and to clean up the code base, and again the plan is to make this transition as smooth as possible. Additionally, it is planned to come up with a two-sided release schedule: there will be a release every six months, but there will also be long time rhythm for larger aims and features.

These aims sound and ideas sound reasonable – and do remind of course of the KDE 4 process. I do hope for the GNOME team that they had a close look at the KDE 4 process and learned from it: many things worked out surprisingly well, some things didn’t, and they can copy the first and learn from the second, why not.
I must admit though that I wonder how the “first-clean” idea can be realized – at least for KDE that would not have worked. Or said different: where such an approach was used it was also strongly criticized. The best example here is probably the KDE-PIM suite: as part of KDE, it was cleaned and will be introduced first again with KDE 4.1. Many people missed it heavily, although of course it was made sure that KDE-PIM-3 worked perfectly well with KDE 3, so a smooth transition is indeed possible. With the plasma panel a simple version of a panel was introduced to build upon, and again there have been many critics.
Also, sometimes straight cuts are necessary – think of arts->Phonon here.

Anyway, in the end GNOME is a quite different project compared to KDE, so it is difficult to compare both. But they will face some similar problems, and so it would not be the worst idea to see and learn from the KDE experiences. It’s always easier if something is done a second time because you have the experience from the first run, but good luck nevertheless! :)

Short Tip: Using Brother MFC-5840nc printer in Linux/Fedora

Tux
Brother printers are usually not supported out of the box on Linux. However, the company provides drivers for Linux which are working. In this case the printer is a Brother MFC-5840nc connected via LAN.
Brother provides two packages (rpm and deb) which have to be installed in that case: the lpr drivers and the a cups wrapper. Both packages for the appropriate printer must be downloaded. Afterwards, a new printer is already registered with the system but must be configured right: by default it is registered as a USB connected printer which in case of a LAN connection is of course wrong.
The easiest way to configure the printer is to access http://localhost:631/printers/ which is an interface to the printing system. In case of Fedora the root password is needed to store the configuration changes. When everything is set up a test page can be sent to the printer.

The printer also appears in other applications like in KDE/GNOME apps.

Forth and back again – having a look at Fedora 9 and KDE 4.1beta

kde-logo-official
Recently my distribution of choice, Fedora, published a new version, Fedora 9. This one featured KDE 4.0, and there were also KDE 4.0.80 packages available, and I decided to take a look at them. Unfortunately, I had to return to Fedora 8 and KDE 3.5.9 – but not for long, that’s for sure.

The background

Recently I wanted to try two new “tools” – Fedora 9 and KDE 4.1dev. The reason behind was that both came along with a whole bunch of new features. Fedora 9 promised full disk encryption, a new X-server, PackageKit, a new NetworkManger, Upstart and so on, while KDE 4.1dev promised me first and foremost KDE 4.x. I was still in KDE 3.5.9 because I had to write a thesis during the upcoming of KDE 4.0 and wasn’t able to switch. Therefore I decided to install Fedora 9 and afterwards update the system to KDE 4.80 with packages from kdeforge. KDE 4.0.x wasn’t an option because I wanted to have the KDE 4 PIM suite.

The bad experiences

However, the journey did not went as well as hoped. First of all Fedora itself did not boot up any faster. Of course I know that switching the init system itself doesn’t make the scripts go faster, but somehow I expected it to go at least a bit faster than maybe a minute. But the problems with the new KDE were more pressing: KDE froze X several times (Gnome didn’t), most often when the kerneloops popup tried to tell me something. This happened regularly after only a few minutes, and made the system unusable. I deactivated kerneloops, selinux and other usual suspects, but X still froze after some minutes most of the times.
Additionally, Plasma is not able to enlarge to a new size when for example an external monitor with a higher resolution is plugged in. That is however my daily setup, and must work before I can switch to KDE 4.x.
Last but not least I had two issues with Dolphin: first of all, the Ctrl key doesn’t work as expected. Seems to be a bug in Qt 4.4, but nevertheless, I rely heavily on that feature. Second, Dolphin is quite slow when scrolling through large folders. I deactivated the information panel and it was quicker, but still not as fast as I am used to from KDE 3.5.

I did suspect that these problems could be related with Fedora or were fixed with newer devel versions of KDE, and therefore I switched my system to OpenSuse 11RC with the unstable KDE 4.1dev packages. But all mentioned problems were still present except for the X freezes (not entirely sure about that one).

So, in the end I had to switch back to KDE 3.5.9. There are only few things, mostly corner cases, which keep me there, but these are, unfortunately, existential to me.

The positive outlook

However: the impression I got from just playing around and testing the system was the same I already got from testing it only for minutes in virtual machines or demoing the system at LinuxTag: KDE 4 is awesome.
One of the best examples work-flow wise is probably the new menu. I newer was a fan of menus (Alt+F2 does the job quicker) and wasn’t really interesting in the change introduced with KDE 4. However, just using it for minutes already changed the way I worked. The ability to search through the menu is a nice and helpful add-on and just makes sense today. But the main advantage is the easy and intuitive way of setting favorites. It is a blast once you get the idea behind it and actually try to use it. I got accustomed to it after minutes, that was almost scary.
Also, I’m someone who never uses icons or links to clutter the wallpaper – but the folder view might be a good solution when I have to work with a bunch of files (think of TeX here, or of merging different images or text files). It still has some rough edges and could use a way to have no background at all, but it is definitely on a very promising way.

Besides these work-flow improvements there are of course the improvements within the apps, and the new apps in general: just some days ago I was chatting with a friend about city distances, and right in the discussion she said “so just check it with Marble”. Well, I would like to!
Another application I’m really looking forward to is Gwenview – the KDE 4 version is very, very neat. Also, KDE3’s KHTML engine is a bit notchy at the edges, holey in the middle and has a crack at one side. But KDE 4’s KHTML engine is much improved and is therefore a reason on its own to switch. And I haven’t even tested yet (that means: used in daily live) apps like Okular or the improved Kopete.

So I am very eager to see the above mentioned bugs fixed and will afterwards give it yet another try. I’m already sure that my work flow will be more efficient, and that’s in the end what really counts!

Closing words

Besides KDE 4.1 there is also Qt 4.4: some new apps I would like to test are based on Qt 4.4: Screenie and Arora/Foxkit are just the most prominent examples.
There are also bew 3rd party KDE 4.x applications: while the “usual” programs like Ktorrent, Krusader, digikam, Amarok or Konversation already have KDE 4.x versions or are working at it, there are also some new interesting programs around, like Audex or KGrubeditor.

Having said that all that, I’m still very happy with KDE 3.5 right now. It is still a supported platform which just works as I expect it, as I am used to. It even gets bugfix updates if necessary, for example KDE 3.5.9 was released after KDE 4.0, and I’m very thankful for it.
So I’m totally free to choose what I want – and that’s the most important point!

Future of FLOSS password storages: combined solution soon?

kde-logo-official
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

cube-with-matrix
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.