My KDE week

openSUSE 11.4 KDE-testing

Posted on: January 30, 2011

It’s been a while and there was nothing special to report, KDE SC 4.5 just worked. In the meantime KDE SC 4.6 was released and openSUSE offers it in KDF as well as KR46 repos. The corresponding Extra and Playground repos are still WIP. Big thanks to everybody who is involved in establishing and maintaining those repos – openSUSE really profits a lot from the (openSUSE-)KDE community that makes it possible to provide such a nice and updated KDE distro.

Those updating from KDE 4.4 which came with openSUSE 11.3 to 4.6 – please save your plasma* files from ~/.kde4/share/config in case plasma crashes after the update. Submitting them to Novell’s bugzilla would be much appreciated in order to get those crashes fixed for openSUSE 11.4. The same applies to all other issues that come up when updating KDE 4.4 to 4.6, e.g. kdepim-related.

KDE SC 4.6

KDE 4.6 has some nice fixes, among them bko bug 163707 which prevented KDE from restoring the resolution set in systemsettings on login. This is especially important to openSUSE users since sax2 is gone and display settings moved into the desktop environment. Plasma seems to become more stable with every release – in fact I did not have any major issues with it since ages and bug fixing is pretty fast as well. Dolphin does also not suffer from buggy dbus packages anymore and with the latest strigi packages I do not encounter any crashes on close or when hovering certain files which did crash dolphin before. Thanks to remur_030 who helped the strigi people tracking the latter down for .msi files and thereby found and fixed some general issue in strigi which could cause crashes.

Desktop search

The desktop search does still not justify its name though since basics are still missing, e.g. context given for search results as all other desktop searches do and kerry + beagle already did years ago. The feature was shown some months ago but is not as such available in KDE 4.6 – thus even in KDE 4.6 all the user gets is a replacement of kfind + tagging which needs a huge database for that simple task.

On top of that there are still issues with virtuoso-t hogging the CPU, its database never decreasing in size but only increasing, even if you remove folders from the “to be indexed”-list and the systray-tool used to suspend the indexing vanished as well decreasing transparency to the user of an app which potentially keeps your hard disk and CPU busy.

Yes, I know there is always a shortage of manpower but IMHO if an app fails to provide the very basic features regarding the functionality its name advertises, it will not gain any acceptance among users and since every xth user is also a developer it will not attract developers either. Thus the extent of this manpower shortage is self-imposed in case of nepomuk aka desktop search.

I think its a bit unfortunate that strigi is always blamed for anything related to the desktop search in KDE although it is just the tool that is used by nepomuk and its usage is up to nepomuk and not strigi itself, i.e. when to start hammering the hard disk, how to handle the results within a database, what results to display when searching, giving the user control and information regarding its activities etc. From my experience strigi devs are quite responsive regarding bugs and questions – although their websites are all pretty much outdated. 🙂


Power-management got worse in KDE 4.6, regressions such as not disabling powermanagement on desktops and thus suspending the display every 10 minutes, the brigtness slider not representing 100% of the brightness supported by the notebook and it still messes with the brightness the user has set. All these were reported some weeks ago already. Let’s hope that KDE SC 4.6.1 fixes those since that seems to be the version that openSUSE 11.4 will ship.

Further having a presentation-scheme (no suspend, no dimming etc.) is kind of useless with KDE 4.6 since it will change to the next scheme if the battery hits any limit. Thus you have to permanently watch the status and switch back to the presentation-scheme to be save of a suspending notebook while you watch a movie within the presentation or during some longer discussion which leads to you not moving the mouse for some minutes.

Ignoring the scheme the user manually set does indeed make sense but only for the last 5% of your battery and in order to avoid the notebook just turning off because there was no power left.

openSUSE 11.4 milestones also features a power-management bug that makes your hard disk suspend every few minutes, confirmed but no fix so far.


For openSUSE 11.4 there is still one major mystery bug to solve for openSUSE 32-bit NVIDIA users which get several apps crashing since they updated to KDE >= 4.5.


For openSUSE 11.4 we are currently testing kpackagekit/apper as a replacement for the unmaintained kupdateapplet. Kpackagekit works ok but it seems that its zypper backend could need some improvements. And the next version of kpackagekit which will be called apper features monochrome systray icons which is fine, but the “security patch available” signal is just a tiny red dot which is hardly visible, especially if your eye-sight is not the best or you are suffering red-green colour blindness. So most issues with kpackagekit are not actually kpackagekit’s fault but either backend-related or touching artists’ taste.


Another application to test is the phonon-backend to be used in openSUSE 11.4 by default. Should we stay with xine whose backend is apparently unmaintained but has served most users well, switch to the vlc-backend or maybe use the gstreamer-backend?

Trying to play some file with amarok and the gstreamer-backend brings up some dialogue (/usr/lib/gst-install-plugins-helper) that asks whether it should search for some package, I guess codecs. If one clicks on “search” kpackagekit opens up and claims instantly that “Getting what provides” finished but does not do anything. This is on 11.3 plus KDE 4.6 from KDF, so let’s hope it works better on 11.4.

The vlc-backend consumes the double amount of CPU for playing the same mp3 via amarok. 8% instead of 4% might not be that much in absolute terms but a 100% waste nonetheless and especially on mobile devices everything that wastes battery should be avoided. Further there seem to be issues playing video via vlc, some apps like dragonplayer.


And finally there is of course the always present issue of KDE-PIM. openSUSE 11.4 will ship kdepim 4.4.10 which needs testing. There is especially one annoying bug which makes kontact crash when logging in if the last view before logging out was kmail. So let’s hope this can be fixed before 11.4 gets released.

I was really looking forward to KDE-PIM 4.6 since IMAP-support seems a lot better with akonadi, at least for my use-cases which include suspending/resuming. The latter makes KDE-PIM 4.4’s imap slave fail and not recover which works fine with KDE-PIM 4.6. You can get regularly updated packages for the latter off openSUSE’s UNSTABLE KDE repo.

Help testing

Please help testing KDE SC 4.6 from the openSUSE repos in order to make it shine in openSUSE 11.4. Feedback can go to the related wiki pages or straight to opensuse-kde@.


39 Responses to "openSUSE 11.4 KDE-testing"

I love how you give only negative testing feedback. Except perhaps for the fixing of one bug…
Very motivational for all the devs that worked there ass off.
I really like your blog, but don’t forget about good news. Writing nice things is harder, but a lot more fun too read!

grtz, a kde interested xfce user

I did mention that there was nothing special to report until the release of KDE 4.6 since everything just worked. “everything just working” is a compliment, don’t you think?

And regarding nepomuk. I tried, I really tried and defended that bit but I gave up because defending a desktop search which does not want to be a desktop search is futile.

I will pay more attention to the positive things though since it might not be that obvious that only mentioning those few issues does mean that everything else is in pretty good shape. What about this: thanks to alin openSUSE can offer daily svn snapshots of digikam 2.0 which includes face detection and image versioning! 🙂

Nepomuk isn’t Beagle, isn’t Kerry. Please, compile Bangarang 2.0 and you’ll have a slight better understanding of what Nepomuk really is. And I’m no developer.

What you don’t get is that I did not choose its name! Open systemsettings and read yourself it names itself “desktop search”. Thus and only because of this I expect it to be a desktop search and fulfill the basic features a stand of the art desktop search should offer. There is nothing to understand about nepomuk, there is only its name that mediates its purpose and thereby establishes the expectations a user has.

And again, I can only state that they brought it on themselves by picking the wrong name – in case they do not want to be a desktop search. Name it “tag search” or “sematic desktop” or whatever but do not blame others for expecting a desktop search if you call yourself that way.

Easy to prove: open google and search for desktop search. There you can see what “desktop search” stands for.

I think he did a nice job. He pointed out that Plasma becomes more and more stable and rock solid. The same goes for Dolphin.

But for people like me we who are quite nervous and excited about the umcoming release this blog post was very enighting. Sometimes it makes sense to adress those issues directly and I suppose the developers will understand this.

I added some positive feedback since he is absolutely right that one should never forget to mention the positive things when pointing out bugs. 🙂

The NVIDIA bug number is 251719.

Thanks for pointing that out, I updated the link.

[…] This post was mentioned on Twitter by openSUSE News, Komenk Alphandhie. Komenk Alphandhie said: i like that!! RT@openSUSE Planet #openSUSE: KDE at openSUSE: openSUSE 11.4 KDE-testing […]

For virtuoso-t, it seems that disabling the contacts and desktop search krunners. After following that advice, I have no problems with strigi/virtuoso/nepomuk. The issues are being worked on, so hopefully they will be solved soon!

Your link from “the feature was shown some months ago” points to the same br as the next one about cpu hogging – where was it meant to point?

I really have to test the links before posting. Thanks for the hint, I corrected the URL.

I hope it gets fixed as well since these issues are putting people off who might want to try nepomuk.

If you read the bottom comments at bko#246678, Sebastian Trueg and I have been very busy solving the bug. We have basically solved it and are only working now on an efficient way to convert users’ existing nepomuk databases.

Will this be backported to KDE 4.5 or what happens to those users?

It’s up to Sebastian really. For me, 4.5 bugs don’t affect openSUSE release users, and 4.6 is now released so I don’t see a need to continue to maintain 4.5.

Your website is unfriendly to KHTML, can not post comments! How ugly…

As for virtuoso, disabling nepomuk-related krunners – contacts and desktop search – seems to make the trouble go away, and I know that the issues are being worked on.

Your link “the feature was shown some months ago” points in the wrong direction i am sure – where was it meant to go?

I fixed the URL, I cannot do anything about the khtml issue since I only use whatever wordpress offers. It’s not like I set some option to keep out khtml. If you tell me how I can improve things I’ll be glad to do so.

There are workarounds but disabling all kinds of features to prevent bugs hitting the user gets tedious. For kontact special dates and the planner had to be disabled and for nepomuk some runners. Indexing got disabled in 11.3 and will be in 11.4 because nepomuk starts it right away and thus decreases KDE’s performance right after the login, apart from the database never cleaning up dead items. etc.

It’s no good if downstream has to disable features.

Your assumption is wrong: File indexing and Nepomuk running are two different things. For 11.4, the plan is to enable Nepomuk, but leave file indexing disabled.

And how does that prove my assumption wrong? Without indexing there is still nepomuk but without nepomuk there is no indexing. Simply because nepomuk is the head and strigi just a tool. How nepomuk makes use of it and its results is mainly up to nepomuk and not strigi.

If nepomuk would handle its indexing tool strigi in a different way, i.e. no hard disk hammering right after login, CPU hogging, proper database management etc. – then the indexing part would not have to be disabled.

On top of that the actual usage of the indexed data by dolphin or runners via nepomuk is another reason to not enable it since its current functionality regarding desktop search does not justify the disadvantages the user is exposed to when indexing would be enabled by default.

So I still claim that it is nepomuk’s fault that indexing happens in a way that makes openSUSE turn it off by default and it is also nepomuk’s fault that the data that can be indexed by the usage of strigi is not presented to the user and accessible in a way state of the art desktop searches do.

As I’m understaning it Nepomuk is not only used in strigi but in Plasma, Bangarang, Dolphin etc.

Maybe those issues would justify to delay the release for some weeks to make it more stable. Your described issues seem to be quite severe and at least I don’t want to run into such powermanagement issues or problems with the update applet.

I am very interested to see a good-working 11.4 release and therefore would rahter wait another two weeks instead of just crashing my system.

There is a RC1 coming in the next weeks, don’t you think that therefore only 4.6.0 will be in the final version?

wstephenson stated that he wants to ship KDE 4.6.1 and since he is currently the KDE-guy at openSUSE he should know whether that’s feasible or not.

Regarding the power-management: it’s more annoying than crashing your system. I’d guess the KDE-related bits will be fixed until 11.4 final. I cannot say anything about the hard disk issue since that does not seem to be KDE-related.

Update: I meant: “it’s rather annoying than crashing your system” or something like ” it is more of an annoyance than crashing your system”. If you read the comment I replied to you will understand. Sorry for the ambigious wording.

The update applet currently performs updates without caring about vendor-changes which is bad but unfortunately not KDE-related either but an issue of the zypper-backend. the gnome update applet suffers the same issue since they both use the PackageKit-zypp-backend.

And what about KDEPim, in case its 4.6 version will be shipped along with SC 4.6.1, will it be part of OpenSUSE 11.4?

TBH, the only real regression with power-management which made it into 4.6.0 is the DPMS disabling feature, which I fixed today and can be worked around with a “xset -dpms” in the meanwhile.

The behavior described with the presentation profile is going to be fixed, but is identical to how 4.5 behaved, so it’s more like something which was already there (and any other scheme-based power manager does)

More than that, I don’t see any other worse-than-crashing annoyances

There are more regressions e.g. that the brightness slider in the kcm does not represent 100%. Long reported. And there are still issues with ignoring the manually set brightness-level similar to the scheme issue.

Anyway, regarding the “it’s more annoying than crashing” you refer to, I just read my reply again and spotted the bug. 🙂 I meant: “it’s rather annoying than crashing your system” or something like ” it is more of an annoyance than crashing your system”. If you read the comment I replied to you will understand. Sorry for the ambigious wording.

That one (slider) should be actually fixed in 4.6.0. If it is not, I’d please ask you to verify if it is fixed in 4.6 branch, in that case the commit somehow did not make it into the tag. Otherwise, please reopen the bug (261622).

Np for the misunderstanding, mistyping happens ^^

I think feedback like this is very important. Sometimes it seems that most components are developed in isolation and only get “tested” together when they reach the user, and it’s hard forcing every user to become a tester, bug-reporter, and all that if you’re trying to be more than a “geek curiosity os”.

Also, with some bugs are only going to be fixed “on the next release” so for big groups of things like KDE SC 4.6, plasma and apps, it seems you keep trading a set of bugs for another, and always on the upgrade tread-mill hoping that the next one will solve more than it breaks. A solution? I don’t know, but we do have to acknowledge that the problem is there.

And yes I try to do my part and have already submitted a patch for a bug I saw in 4.6, and additionally reported some others.

While you point a common problem with KDE imo, you miss the point a bit which is not so unimportant for your argument.

It is true that KDE carries a set of regressions and annoyances since the jump away from 3.5. This had some tough effects on the KDE community and has set the matujrity of the platform back. Also being a long time KDE (since 3.2) user and KDE contributer, at some point it took me too much time and resources to use KDE 4.0-3 desktop, so I switched over to Gnome for some months. I have really appreciated it, but you could feel that the programs are limited to a very specific set of use cases. KDE does not nearly compare here. While most software is written for a special use case, it is rather concepted from the ground up to provide libraries and frameworks to tackle the technical (both in terms of model and in terms of view). Since the view with its use case does not come first, but is rather adopted through the period of the infrastuctural build-up of the related technoligies, it has often unmatured features/combinations involved. This hits the user especially when the platform is partially rebuild from the ground like in the 4 cyclus. What would have been the alternative?

Compared to the backup of Gnome by Redhat, Ubuntu, SuSE and others, KDE has a very technical community background. This is changing with the adoption of Qt by Nokia (maybe even by Ubuntu) and its interest in KDE software like KOffice. I would say that, if you disable Nepomuk, KDE 4.6 is end-user ready. It might have some glitches, but nothing where you don’t come around. But it is not as mature as KDE 3.5 or Gnome 2.* are. This has to do with the ambitions in many KDE technologies and the far way of building these frameworks correctly up. Yet in the end KDE gives you of *all* platforms by far the most control and the most flexible frameworks you could imagine. This is not really necessary for the end-user in the short-term, but pays off by proper code-sharing and maturing over time like it for 3.5 did.

It is really not the case that KDE developers don’t care for end-users, it is rather the priority to first get the technologies (model) setup in the most generic and code-sharing way, before caring for features or fixing bugs. Still they do fix bugs in the release circle and I don’t think KDE 4.6 is that bad anymore. In most cases it has already by far paid-off to rethink the architecture and build in intelligent features and integration in others it will soon. I think nepomuk will *rock* once it is properly running and integrated, but it is a world-wide novelty on the desktop. You won’t get that anywhere else, neither in Gnome (with Firefox, OpenOffice, Mono-stuff and other non-Gnome parts) or in any lighter DE, leaving alone the commercial sh*t.

The attraction to KDE comes from this fact, so if KDE developers would switch their perspective to end-user first (like Gnome does), as you suggest, it would become very much like Gnome. If you want a really mature desktop you should atm. likely chose it. But if you are already interested in the more advanced features of KDE, regarding technical stuff like KParts, DBus (KDE applications have much wider DBus interfaces), … or rich GUI’s well integrated in the system, you should stick to KDE. It is really not getting in the way too much.

The only proposal that would make sense, instead of proposing a whole new strategy imo, would be to create a Usability initiative with frustrated users at hand where interested developers could help fix use-cases and polish their software. And you know what? You can do that already, go to IRC get involved with a little bit of your time and you will see that many devs are very willing to help you fix their bugs/document usability work-flows.

Just my loooong 2¢.

Humm I see my comment came out rather more negative than I wanted.

Don’t take me wrong, I’ve been a KDE user for a long time, and I was running plasma from trunk when plasma wasn’t even able to draw a panel. Never wanted to go back to 3.5, or gnome (do try it regularly, and recommend it to friends, but it’s not for me).

And why am I a KDE user? For all the reasons you listed, and more.
I’m pretty happy with 4.6 on my two desktops, it was the smoothest upgrade so far in the 4.X series, but for example the pointed out power management problems are very serious, and what I wanted to convey is that it unfortunate that you need to have latest-KDE if you want latest-fixes, but you also risk having new bugs, so it’s always a tradeoff.

But yeah, it’s getting better with each release, and I’m staying on the train, I just wish it went faster 🙂

@ianjo: Ok, cool, that we have a consensus here. I also tend to recommend Gnome for n00bs, but I don’t feel very comfortable with it and KDE 4.6 looks pretty recommendable already.

What I wanted to point out is that for KDE new bugs in new features belong a bit to the development model. Since KDE is not concentrated on specific use cases which are checked and extensively tested before a release, but rather allows all kind of workflows and tries to make them as flexible as possible, you’ll always have some bugs in .0 releases. If you wait a bit for .3 or .4 (which is also the strategy by Debian btw.) you usually get most bugs fixed and no serious regressions. But the only way to ensure that your setup will work with the next release is to test it and take the pain during beta and rc cycles to find out bugs in the first place.
At least this what I do, although it hurts sometimes badly…

My whole point was though, that it is not constantly regressing in the same places over releases, but KDE development rather builds a very mature core, but still has single points of constructions and an outer sphere of exploration. Your statement rather looks like it would be repeating the same problems without progress in maturity.

yes it was the smoothest upgrade (from 4.5 to 4.6) for long – congrats for that.

nevertheless i think we should get a comprehensive possibility to check and/or reset some of the configurations (rc files), which may carry along old configs and cause iritating behaviour.

khtml – I think it lost some functionality but nevertheless webkit does a nice job for most pages.

Virtuoso/nepomuk definitely needs some love, it wouldn’t be a problem if kdepim wasn’t using it, they are using this stuff before its ready.
Wise choice using kdepim 4.4, it’s definetively a good idea, until virtuoso doesn’t consume cpu unnecessarily.
About regressions, 4.x.0 releases has always been like this AFAIK, these things usually sort out for 4.x.1 or 4.x.2. All we can do is help make patches to send to 4.x.1, and release opensuse 11.4 with that. Also all 4.x.x versions should be automatically updated, they don’t break thing, except in rare cases.
Phonon backend is a though decision, xine is unmaintained, gstreamer always gave me problems, it’s mostly broken (not gstreamer itself I think it’s only phonon backend), I would have gone for vlc, but that cpu problem is worrying. The best choice might be staying with xine as it just works, and moving to vlc if these issues are solved, or at least reduced.

“Virtuoso/nepomuk definitely needs some love, it wouldn’t be a problem if kdepim wasn’t using it, they are using this stuff before its ready.”

But stuff won’t be ready before it gets used.


About Gstreamer: I would rather try to use that and get the bugs fixed in there. Not only is this the likely the future multimedia framework on Linux which is shared between both Gnome and KDE, it is also extensively tested with things like Pulseaudio and will be the default phonon-backend for Kubuntu as well. Xine is really old and does not offer much more space for new features (like video/audio input support, …). VLC is a bad choice as pointed out by a VLC dev for Kubuntu (was somewhere in apacheloggers statements I think), because it is not a multimedia framework, but rather a single application stack hammered out in a library. If you want to inegrate things nicely you should chose the most-shared framework in the FOSS-stack.
GStreamer is broader and btw. also supported by Nokia, so the best imo would be to go with GStreamer and try to get outstanding bugs fixed until the release.

very concise update, exactly what I was looking for! 🙂 thx

Ok, I am asking every one I met to read this post!

“Power-management got worse in KDE 4.6, regressions such as not disabling powermanagement on desktops and thus suspending the display every 10 minutes, the brigtness slider not representing 100% of the brightness supported by the notebook and it still messes with the brightness the user has set.”

This just makes me cringe. If KDE wants to win me back as a user, the level of quality needs to go up _a lot_. Bugs like these made me leave to a non-KDE distribution.

Hm, actually that’s bogus. These bugs might be annoying but only having 90% of 100% won’t hinder you to do your work. It’s just a keystroke or a click on the battery icon to increase the brightness to 100%.

Even less of an issue regarding getting work done is the other bug (which got fixed already), i.e. the suspending display. Assuming you use your mouse or type while working or use a notebook for working you won’t even notice it. It’s rather an issue for activities like watchign a DVD.

So if these bugs made you leave, then I guess you are better off with some other DE. KDE 4.6 is of high quality as you can see by me only mentioning bugs that do not hinder your work at all.

Good job on the post although it’s different than my own KDE experience slightly. I think the bugs you experience depend on what level of a user you are.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: