There is something magical about hacking on things without having much clue about them. It almost feels like a treasure hunt, with mysterious traps all along the way and an elusive treasure maybe at the end. Today's treasure is KDE4's Konsole (preferably not) being awfully slow with some fonts. Specifically, as irony would dictate, the rule could be almost said that the better suited font for Konsole the slower the text rendering is, whereas if the font breaks the text layout completely or hurts to look at, the speed is just fine.

Profiling showed only that the CPU time was all spent in the X server in the nvidia driver, which is really not that helpful with something that is closed-source. It only meant that Qt was feeding to X something that the driver didn't like much. Eventually, I tracked it down to one XRenderCompositeText32() call in Qt (which, in a retrospect, wasn't really a very obscure hint - if there's something slow with drawing, suspecting XRender is always a worthwhile guess).

That showed where the treasure was, but now there was the part of getting it. Not that easy if the knowledge about font rendering doesn't go much further than knowing it's drawing text. Especially when it turned out that disabling the XRender path in the code resulted in some fonts being shifted one pixel down (and only some of them, so that it wouldn't be too simple).

But anyway, to make the story short, for those who want a share in the treasure, the patch is in the Qt bugtracker, waiting for somebody with more knowledge to answer the questions for which I don't know the answers. And home:lllunak:branches:KDE:Qt and home:llunak:branches:KDE:Qt:STABLE repositories have the 4.6/4.5 Qt packages with the patch added.

So, openSUSE 11.2 is out, and that means a lot of people start using it and, well, occassionally run into bugs and sometimes even report them. As much as 11.2 appears to be a fine release, this is bound to happen now too, and that means that the number of KDE bugreports for openSUSE in the Novell bugzilla will grow again and will need to be handled.

And now it seems to be a good time to do some housekeeping there. Many of the bugreports there are old by now, for older KDE releases, or even for openSUSE releases that are no longer supported (bye bye openSUSE 10.3). Having too many bugreports means a lot of effort needs to be spent just managing them - if developers and packages are supposed to fix problems, they first need to know which ones are important and should be worked on first. For this reason we have guidelines for sorting KDE bugreports, however, with the recent the release of 11.2, there hasn't been time to review all recent bugreports, and many of other bugreports are not valid anymore.

This is exactly the time when you can help KDE in openSUSE. If you like the 11.2 release and would like to contribute back, if you've already wanted to contribute but didn't know how or thought that you don't have the required knowledge, or even if there is a bug you'd like to see fixed and would want to help the developers and packagers to have more time to concentrace on it, this is the chance. We are starting another KDE bug squashing session, with the aim to review and sort all KDE bugreports for openSUSE. And it is not difficult - all you need is openSUSE 11.2 installed, the ability to use Bugzilla, and the howto describing all the details.

So if you want to be part of the openSUSE KDE team, come (today, tomorrow, this week, whenever you want) to #opensuse-kde IRC channel on FreeNode, ask if you have any questions, consult the howto and you can pick from the prepared groups of bugreports and let's squash some of those bugs.

Oh, yes, just in case you haven't noticed, it's out. However, since I maintain this image of seriousness, purposefulness and so on (which I only occassionally spoil by something like doing strange things to my hair, eating way too much icecream or doing silly things at SUSE outdoor events), I would like here to reference the KDE release notes for openSUSE 11.2. We recalled at least the Pulse Audio thing a bit too late, so maybe right now the actual release notes do not mention it yet.

Default Web Browser - yes, we default to Firefox with KDE integration, see the notes for switching back. Nothing more to say here, if you still don't know about this, you apparently don't know about KDE and openSUSE (in which case you're kindly asked to fix that ).

KDE3 - boy, I'm getting really tired of this topic . It's really simple: Apparently there is nobody caring about KDE3 enough to do something about it. So, if you are in the minority that still doesn't find KDE4.3 good enough as a replacement, either just stick with an older release, or try to use the unsupported KDE:KDE3 repository, which right now looks like it still builds, but may not anymore tomorrow if anything changes, since, as I said, everybody feels like having more important things to do than spent time on it (really, we tried to find people who'd be interested in it, but apparently all people capable of doing so already work on KDE4 or are too busy complaining on mailing lists). So, just get over it. KDE3 is dead. It is no more. It has ceased to be. It has expired. It is an ex-KDE3. (Thinking of it, I will skip that is has gone on to meet its maker, just in case).

Strigi/Nepomuk - they are disabled by default. With Beagle not enabled by default being asked a lot for, and generally considering the situation, we decided this would be a better option (and upstream wasn't really against). Those who want them enabled can easily do so in systemsettings. Well, almost - unfortunately a problem slipped in that prevents starting Strigi in default installations. See comment #6 in the #548007 bugreport for an easy fix.

PulseAudio - since KDE not only does not have a hard dependency on PA but also there is basically no integration of PA, having PA with KDE doesn't buy anything to most users, so we decided to disable it by default in KDE installs. This is not the broken PA that was in 11.1, but still, why force it unnecessarily. Those that have a use for PA need to enable it in the YaST Sound module (note that this includes everything running on a system that has KDE as the default desktop).

Now, onto the goodies!

Now that the mention of the Firefox KDE integration I've done has reached also the dot, I guess it's time for a couple of things that don't quite fit into an article but I should probably say them somewhere anyway.

First of all, this is nothing against Konqueror. I still use Konqueror. In fact when a couple of months back there was a wave of "let's ditch Konqueror" voices on the planet and kde-core-devel, I was one of the people opposing that (and I still think it's not an option, as Konqueror is still the best KDE browser there is - Aurora is Qt-only, Rekonq is at version 0.<somesmallnumber>). For the next openSUSE release we will evaluate the possibilities again and Konqy may end up as the default again if it's considered to be up to the job. Speaking of which, Konqueror has never really been 100% default in openSUSE, as the desktop icon, which is what the common user uses, has always been Firefox, so we can also say the we just fixed the inconsistency (and it's really simple to switch it back). But the real reason was that many people are simply not satisfied with Konqueror, so we decided to try to not ignore the reality for a change. I myself use Konqueror, but if somebody else wants to browse the net on my home machine, they get Firefox. I don't like this, but what the hell, c'est la vie.

So, when we decided to make Firefox the default, we also faced the problem that we switched to something that from KDE user's point of view sucked in pretty much all aspects except for the browsing itself. The idea of Firefox desktop integration on Unix ranges from not bothering with it at all, over using generic not-really-desktop stuff like mailcap, to thinking Unix==GNOME. Normal Firefox in KDE offers to open PDF files with Evince, shows /usr/bin in a filedialog when you decide you'd like to open the PDF in some other application, has inconsistent (not just reversed) button order in dialogs and other yummy things. There have been attempts to solve this e.g. by creating a Qt version of Firefox, but those AFAIK have never led to something usable in practice, and with WebKit now part of Qt I somehow fail to see the motivation for anybody to try once more. And in this situation we had just a short time before openSUSE 11.2 feature freeze.

The trick, of course, was using magic. The Firefox with KDE integration is still the same Gtk Firefox, just with a bunch of hooks calling an external helper. I don't have the ability of some other KDE developers to have clones, and I'm not crazy enough to try to mix Gtk and Qt in one process (which, despite the possibility of a shared event loop, should be nowhere near trivial). So it's nowhere near the extent of the Qt port, and maybe that's why it has worked out (as we all should know, perfect is the enemy of good).

The helper and the patches at available in a Gitorious repository, they are made to match the openSUSE package so they may not possibly apply cleanly to upstream sources, but feel free to play with it. Actually, you are more than welcome to do anything you want with it (wanna be the maintainer of it? no problem). With the problem more or less solved, and with other things to do, I don't have any further big plans for it. I will try to push this upstream if possible (I have no idea what faces will Firefox developers make when they see it), but besides that, there are still many other areas that need some magic. And, after all, the ultimate plan is still that Konqy will one day rule the world .

Since it seems it will turn up quite often, I would like to answer the question 'Will openSUSE 11.2 include KDE 4.3.2?'. The short answer is no and yes .

The 4.3.2 release of KDE came too late to be included in openSUSE 11.2. As the distribution release gets closer, there is a certain point after which only reviewed changes should be allowed in, in order to reduce the possibility of these changes causing unexpected breakages that might go unnoticed within the relatively short time until the release. This can happen and it wouldn't be very good to fix something small and break something bigger for the release because of some unnoticed mistake. So openSUSE 11.2 will not officially include KDE 4.3.2.

As can be probably seen from the 'officially' in the previous sentence , this is not all, as openSUSE 11.2 will, in practice, almost include KDE 4.3.2. We were updating from the 4.3 branch until few days before KDE 4.3.2, and were still including bugfixes that were important enough even after that. So if you care more about how it works than what sticker is slapped on top of it, then you shouldn't need to worry.

And additionally, of course, it is possible to install 4.3.2 from the KDE:43 repository, where new stable KDE releases are packaged as long as KDE:KDE4:Factory:Desktop is frozen for openSUSE 11.2.

The decision on the matter of the (not)preselected desktop in openSUSE has been made. You can read about it in the mail announcing the decision, I would like to just offer a KDE view, from Will and me.

What happens now is that in the desktop selection screen during installation there will be the KDE radio button preselected. That's all, folks. Nothing more, nothing else. It doesn't mean KDE gets better somewhere else, no new KDE developers are going to magically appear on the KDE team, this means nothing for SLED, and it means nothing for other parts of openSUSE. Therefore, in case you feel a strange urge to start publically shouting "Victory!" or saying something about GNOME getting dumped, do yourself a favour and don't bother trying to look like a pyromaniac (besides, I think there still will be enough of those and you'd just get lost in the crowd). The openSUSE distribution wants to be a distribution for all and this means that KDE is one part of openSUSE alongside GNOME, Xfce, Firefox, OpenOffice.org and others. If KOffice one days gets more popular in openSUSE than OpenOffice.org, it becomes the default. If GNOME one day becomes more popular in openSUSE than KDE, it becomes the default. As simple as that.

However, I believe that even this small change can achieve a lot for KDE. Some people, when supporting the openFATE feature, expressed their opinion that making openSUSE focus on KDE would make openSUSE the best KDE distribution. But openSUSE is not some magic creature that gestures and makes things happen, it is the community that does that, and there is nothing preventing you from taking a part in making KDE in openSUSE even better. Since that is how you can also look at this whole issue - I hope this is enough to show that openSUSE really wants to be a community distribution open to all. So if you have doubted that for whatever reason, you might try to look again and reconsider. Or, of course, even if you are just looking for a distro with good KDE, you could check out openSUSE too .

A few technical details ... er, a shameless plug ... well, simply , in case you want to give it a try right now, a couple of things that could help you. First of all, the latest openSUSE release is 11.1, which includes KDE 4.1.3, and openSUSE 11.2 with KDE 4.3 is in development. Don't faint, the fix is simple - you can try either installing from a 11.1-based LiveCD with KDE 4.3 created by Stephan Binner, or you can upgrade KDE in 11.1 using either zypper or 1-Click (note you will have to confirm vendor changes because of switching to a different repository). More information about KDE in openSUSE, including the mailing list, IRC channel, build service (you'll hear about that one again) can be found in the openSUSE Wiki. So, all those of you who wanted openSUSE to be the best KDE distribution out there, let's see about it.

Do you want to write something about KDE's memory usage? Simple, just follow these steps:

1. Launch KDE.
2. Run some random tool for measuring memory usage, preferably top.
3. Pick a column you think you know what it means. If you can't decide, just pick one, preferably something with big numbers (big numbers look better, remember).
4. Complain that the numbers are way too big. For higher bonus, compare it to something else, preferably something that gets nowhere near KDE's usage of shared resources (=libraries, mostly, but not only).
5. ???
6. Profit!

Really, it's as simple as that. So many people do it, you can too. See, for example, this review of KDE4.3. I have nothing against the review itself, since, I admit, I mostly skimmed over it, only two things caught my attention. First one was getting it backwards who copied from who the filtering feature in Present Windows compositing effect, which slightly amused me, and second one was the part talking about resources, which didn't.

The first item there is about kioslaves supposedly staying running for way too long, and it's not interesting here (although I like how it says "I suspect", like if checking it for real and then creating a bugreport is way too much work). The second item is about KWrited taking, imagine it, 18M of memory, and the last one is about the nVidia libraries wasting a good amount of memory, again.

Checking the KWrited item (I guess I was curious, or maybe bored) showed me several things. First of all, I don't have any KWrited daemon - openSUSE has libutempter, which allows building KWrited just as a KDED module. So instead I took KAccess, which should get similar treatment and not run on every system when it's mostly useless. Looking at numbers in top showed resident memory usage (RSS) 40M and shared memory usage (SHR) 25M. That was interesting for several reasons, like 40M being quite a lot, even for shared usage (since resident memory usage includes also all shared stuff, and so it doesn't really mean that much), or the fact that unshared memory usage for a small daemon being 40M-25M=15M is just plain rubbish.

The 40M is actually easy to explain - it is loaded using kdeinit, so it includes all memory from the basic libraries that are preloaded by kdeinit and shared by everything it launches. That includes the ~10M unshared bonus from nVidia libGL libraries that kdeinit helps to share.

The seeming 15M of unshared memory was more interesting and strange. Checking /proc/PID/status confirmed that data of the process is nowhere near that and that there must be something wrong going on. Checking /proc/PID/smaps in details showed similar results, again nothing anywhere near 15M. It is also not nVidia, since the memory is marked as dirty, but shared. And then it suddenly was obvious. The kernel (since that is whose numbers top blindly repeats) doesn't consider dirty shared memory to be really shared. A major portion of the 15M is the position-fixing of the non-PIC nVidia libraries, and some of it is also memory taken by symbol-binding to libraries. If a shared memory is dirty, then it may be dirty, but it is still shared. It got dirty before kdeinit started forking off new processes for launching, so it must be shared. Checking with Exmap, the only memory tool I trust so far, confirms. It is still some memory taken (and still big enough for those who don't know which year it is), but it's much smaller than what it seemed like.

Now, no wonder pretty much nobody can get KDE's resource usage right, when both people don't understand it and tools report nonsense. As it is said, two wrongs don't make a right. Here, they usually just make only a bigger wrong.

So, John, I think I might know what you could add to KSysGuard, after all. You could try to make KSysGuard a memory measuring tool that, unlike the rest, doesn't suck and make people write nonsense about KDE's resource usage. The magic line, in bash terms, is:

Where PID is pid and TYPE is:

• Size - that, as http://ktown.kde.org/~seli/memory/analysis.html says, means next to nothing in practice, so if you use it, make sure to hide it well.
• Rss - resident memory usage, all memory the process uses. While somewhat interesting as the grand total, not really that good number on its own, as a good portion of it is shared with many other process. Put it somewhere in the back.
• Shared - (i.e. Shared_Dirty and Shared_Clean together), the total amount of memory shared, what would SHR in top be, if it wasn't broken. Not really that interesting, unless somebody wants to admire how good we are at reusing stuff.
• Private - (again, both Private_Dirty and Private_Clean), the memory of the process itself, its own memory that is not shared with anything. It is probably worth the second memory column, after Pss below.
• Swap - I guess it says something useful too, but with my machine's swap being pretty much useless, I can't quite say .
• References - with documentation for smaps not being what it should be (that is, existing), I can't quite say what it is, but I think it is for measuring statistics about how much memory a process accesses over a time. There seems to be a way to reset the number. For KSysGuard, probably useless. However, when trying to find out in kernel sources about it, I found a nice little gem, the next entry.
• Pss - this is the thing I love about Exmap. It is not as good as what Exmap can do, but it's good enough. It means, according to the sources, Proportional Set Size, and it is Rss adjusted for sharing. If a process has 1M private and 10M shared between 10 processes in total, Pss is 1+10/1=2M. In other words, this is the number that can take into account the fact that KDE applications massively share memory. This should be THE memory column in KSysguard.

I hope this can work out for KSysGuard. I am slightly worried that fetching all these numbers from kernel will take too much time, but that needs to be tried. But, if it will work, do we all now know what will be so special about KSysguard?

I noticed yesterday that at the kde-apps.org page for WMIface, a tool that allowed scripting the window manager used by KDE3 from command line, a comment appeared asking about a version for KDE4. It felt like a good idea to do something as simple as this in the evening as a relaxation, so, after quite some time playing with C++ templates and so on (since I'm a lazy developer and therefore I went with doing some extra work that would save me from doing work), I have to disappoint you. There is no version specifically for KDE4. In order to reduce the dependencies I made it depend on just QtCore and X11 libs, with those few important classes from kdeui copied into the project. No KDE dependency whatsoever. This provides the CLI tool with startup time decent enough for direct usage, and makes it usable on every system, KDE, GNOME, Xfce, whatever.

PS: The possibility of the much more powerful scripting in KWin itself is still there for anybody interested enough to do it.
PPS: Anybody who ignores the kdeui classes for window management and uses this user scripting tool from an application will be tarred, feathered and publicly laughed at. You've been warned.
PPPS: Every decent system, that is - anything that has QtCore and a reasonably wm-spec-compatible window manager.

This may look like beating a dead horse, but it seems like many people discussing the WebKit issue not only actually don't have much of a relevant technical knowledge, but even fail to simply do a reality check. Because I have tried the WebKit KPart and while I can't say it worked perfectly, it worked. I don't see why I should even myself feed my personal data to Google or what's the point of suddenly needing a webpage for friends, so no GMail of Facebook, but I tried a couple of sites, including YouTube or using two online bank systems to make payments, and I mostly got done what I wanted to get done. Ironically the worst breakages I found were search on kde-apps.org or Martin Graesslin's blog, which possibly may be bugs in WebKit itself. Not that I tried that hard to break it, but after all, you can try out WebKit in Konqueror for yourself (openSUSE users can get the WebKit KPart from the KDE:KDE4:Factory:Desktop repository together with the rest of KDE4.3RC1) Change the association in 'keditfiletype text/html' or temporarily in Konqueror's View menu.

Now, I'd like to stress the part about it not being perfect now, not even close. It worked, it was usable, but it had some pretty rough edges. Still, I have to wonder more and more why really it takes so long to get the WebKit KPart ready.

Some opinions on the alternative ways of using WebKit in KDE seem to me to be rather confused too. One doesn't even need to actually try Arora or Rekonq (and I haven't, to be honest) to realize that neither of these is a suitable candidate for a KDE browser, at least now. Arora has no KDE integration whatsoever, nor does it plan to have it from what I understood. It may be a fine browser otherwise, but this completely rules it out as the KDE browser. And Rekonq, or any other Arora fork, first needs to do the KDE integration. That may happen, and this browser may even become the web Dolphin, I just don't think it's less work than having the browser already done and only doing the KDE integration for WebKit. Especially given that KDE integration for WebKit in Rekonq or Konqueror should be basically one and the same thing (code reuse, remember? we are known for it).

As for the blog entry I'm referring to in the title, there possibly may be parts in Konqueror that are written with KHTML in mind, if nothing else because until WebKit KPart there was only KHTMLPart, but it is definitely not the design. If we could switch the file browsing KPart in Konqueror to the one from Dolphin, why should it be a big problem to use another HTML rendering KPart? And while I have digged a bit in Konqueror and WebKit KPart sources, I consider myself to be no Konqueror, KHTML or WebKit expert, so let me just point you to what David Faure says about it.

Really, we have written a lot of good code and invested a lot of time into it. We shouldn't just randomly dump it because everybody and their grandmother think it is a good idea. If we do so, it should be because there are technical reasons. This really reminds me a lot of the KWin vs Compiz problem we had before KDE 4.0. Does somebody still think these days that we should have dumped what we had working for the new kid on the block? If you do, I suggest to do a reality check there too.

Oh, and this blog entry would be 100% written using Konqueror+WebKit, if it managed to post it (ok, so this is ironically the worst breakage I found, life is funny like that). I said it wasn't perfect, there is still work needed. I just still haven't found a good reason why this would be a bad decision or even not reasonably doable.

If you look at for example kde-apps.org or kde-look.org, there are numbers of various KDE applications, utilities, styles, decorations and what not. Various contributors post there their work for others to try and use. This is the place where new software or other contributions often look for their first users.

However, if you look closer, you may notice one problem - most of them are only provided as the source tarball, with no, few or old binary packages. Sadly, here the old jokes about how difficult it is to install software on Linux are still valid - it is not difficult to find applications with comments along the lines of "I tried to compile it, it said <whatever error>, what do I need to do, help". The difference between providing or not providing a simple way to install your newest creation can be the difference between users using it or not.

This may not seem to be that simple to solve though. There are probably only very few people who have all the major KDE distributions installed, let alone actually know how to create packages for all of them and have the time to do that. There are other community members who sometimes provide binary packages, but those only do it for a selected range, and they have to update them as new versions are released. More lucky contributions get picked up and packaged by distributions, but that can be difficult for new ones, since simply they are new and not many users know about them. So it looks like the usual kde-apps/kde-look/whatever contributor needs to depend also on luck to actually even reach the potential users.

Well, for those who still don't know it, let me introduce you: KDE contributors, meet the openSUSE build service; openSUSE build service, this big bunch of people are KDE contributors.

The openSUSE build service is a tool that is used to build the openSUSE distribution, but it can be also used to build additional software for openSUSE (such as the additional KDE repositories that provide various KDE versions). And, what many people might not know, it can be also used to build software for other distributions.

In fact, I've been looking into the possibilities recently, and, in the process of it, I have packaged a bunch of random kde-apps/kde-look stuff in my home repository. And, right now, I have packages for various openSUSE versions and SLED 11, Fedora 10, Fedora 11, Mandriva 2009, Mandriva 2009.1 Spring, Kubuntu 8.10 and Kubuntu 9.04. There are some more distributions supported, for example Debian, but those do not yet have a stable release containing KDE4, so tough luck there.

And I tried to cover various possibilities of what gets posted on kde-apps/kde-look:

• I was probably the first one to package the KWin Aurorae SVG decoration engine by Martin Graesslin soon after he had announced it there, as soon as the necessary KDE4.3 beta2 release entered the KDE4:UNSTABLE repository. I also packaged the Nitrogen KWin decoration, just to have a decoration that builds on more distributions.
• I packaged a set of the Glassified KDM, Plasma and splashscreen themes. The themes were actually just tarballs containing the files (and that actually gave me a hard time when trying to package that for Ubuntu) that need to be uncompressed into the right place, but still, there is the convenience of just installing a package and be done with it.
• I miss the ability switch using keyboard shortcuts between taskbar entries like it was possible with Kicker. There was feature freeze, so instead of providing a patch for Plasma I went for a temporary solution and wrote a simple KDED module hacks that does it. And from the moment I uploaded it to kde-apps as TaskbarSwitch there were also binaries.
• I packaged KShutdown, Ksshaskpass and Kvkbd as examples of various applications. Together with Ksshaskpass I also created a local modification of the openSSH package and sent a request to its maintainer to include a change that enables openSSH to use Ksshaskpass. Kvkbd needed a patch fixing it to work with the XDM/KDM setup on openSUSE.

And the best part about it is that it was actually quite simple and easy. I just took a template for .rpm and .deb packaging, filled it in, tweaked a bit if needed and submitted to the buildservice. Then checked the results after a while, fixed problems and now it is all in home:llunak:kde, ready to be used. Anybody who can code a small KDE application shouldn't have a problem to do the same and then say that the package is in the repository home:<whoever> and that the installation instructions are at http://en.opensuse.org/KDE/Build_Service.

Of course, it was simple and easy for the Lubos Lunak who wanted to package those things, as that was the point. The other Lubos Lunak, the one trying to ensure it was that way, had it a bit harder. The openSUSE Wiki has a lot of information, but it was necessary to read it and try it out. Some work was needed for building from one .spec file for all RPM distributions (really just one .spec, the only package that needed conditionals was Ksshaskpass, and only because I knew the special handling needed to fit with openSUSE's openSSH). It is of course possible to build for each distribution using their .spec syntax, but I wanted the possibility of having just one syntax that would be mapped automatically as necessary using macros and package renames. Some work was (and still is) needed to help making .deb packaging as shared with .rpm packaging as possible (I think I can forget generating it automatically from the .spec, but for example Debian/Kubuntu build system accepts only .tar.gz tarballs, so there is a build service patch from me pending to make the possible conversion automatic).

That work is going to be only mine, though, the plan is still to make it easy for you. Well, ok, I wouldn't mind if at least somebody added better details to the distribution-specific pages linked from the main page, because I e.g. haven't managed to find out how to easily add a new custom repository on other distributions. So if you are waiting now for a howto, this will need to wait for a while, until it is prepared and cleaned up. You can however try to bribe me at Akademy into demoing it personally .