There's been a "small" upgrade to my desktop machine at work, and as a part of that I got my hands on a 1920x1080 Dell monitor and couldn't help placing it as a secondary monitor, rotated. And I couldn't help noticing various problems with this setup.

As already mentioned, I have this certain tool in works that can do various magic when it comes to creating packages, especially for people who have no idea how to do them themselves. And since

too, and on Wednesday I have scheduled a slot for demoing the tool and helping people who'd like to create packages of their software, I've worked on implementing and improving various features that make it more interesting:

• Besides the obvious CMake support, there is now also support for autotools-based software. Autotools stuff is harder to process then CMake (funny, I remember not being very impressed by the move to CMake, but going back now made me wince here and there), but it's already pretty usable.
• Which means that even though the tools is called kde-obs-generator it can handle non-KDE stuff too. For example I have GEdit, Gnumeric or GOffice (why aim low, right?) in my testing project, and while none of that finish the build completely yet, it just needs handling more of the autofoo trickery. I guess the tool is about to need a better name.
• There's QMake support too, kind of. However, if you use QMake, you probably want to switch to CMake anyway.
• The recommended way of use is setting the build service project in a way that presents a more unified build environment, with macros and package name substitutions automatically taking care of distribution differences. This results in the .spec files being quite clean and easy to read. But there is also a mode that doesn't require this setup and builds directly in normal openSUSE, Mandriva and Fedora repositories (and Ubuntu, but that's already different enough from the rest). It means of course that the .spec may have a bunch of %ifdef's and manually written macros at the top, but it works.
• A consequence of this is that it is also usable for creating normal openSUSE packages. If the project build only for openSUSE, the resulting .spec is more or less a normal openSUSE .spec file. I've already watched few times Pavol and Michal explaining packaging to people who would like to learn it, and I couldn't help wondering how scary it has to be for some of them, getting a full .spec file explained line by line on how they need to write it manually. Well, for the next time the introduction part can be greatly reduced to just "run this tool, if it works and you're happy with the result, that's all then".
• There is also the bonus even for somebody who knows how to create packages. It's still nice to have the .spec generated automatically, including all the build requirements (if they are already in the database), the file list and so on. Everything I have posted at kde-apps.org for the last several months has up-to-date binary packages too, and it's almost boring to create them.

So, whoever would be interested, just talk to me at Akademy or come to the Wednesday session and I'll try to help you getting your stuff built and answer any questions (except for the two questions about blue hair - really, people, I've heard both of them already enough times, can't you get at least a bit innovative :) ?).

It is interesting to notice what is sometimes seen as difficult. "It's too hard for me, I can't do that." "I'll never be able to do that, that's nothing for me." Like if most things could be done instantly just by snapping one's fingers. They instead require all these tedious things like effort, trying, learning, practicing and so on. The funny thing is, figuring out things in the IT area is not really that demanding. Wanna write a Plasma applet? There's a step-by-step tutorial at Techbase, just follow it blindly and with a decent skill in reading and typing, tadda, there's a Plasma applet. Wanna a package in the build service? You can use another one as a template, find a tutorial on the wiki or just google for it, and if you'll be just a little lucky, a tool can even do the work for you.

For getting a good comparison of what can difficult actually mean, let me show you something I consider to be pretty hard to learn. To have a better contrast, let's go in some completely different area that has absolutely nothing to do with computers. So if you think something is difficult, instead of doing this whatever something, try doing for example the Salchow jump. And since I expect many people here have no idea what that is, it looks like this, performed by yours truly:

That's roughly it. I assume it looks quite unimpressive to anyone who's never tried it or anything close (and, possibly, in this specific case it probably looks quite unimpressive even to whose who have). Yet this thing was bloody hard to learn for me. I probably learnt coding with Qt quite decently with much less effort (although, that's one of Qt's selling points, isn't it). Writing .spec files and creating packages? Nah, eeeasy. Even getting into Xlib programming was probably less effort, and I read a good part of the Xlib manual as a part of that. I admit getting into compositing effects and adding them to KWin might have been harder than the Salchow though :). Still, for somebody whose reaction to the idea of writting an alternative KDE workspace shell was 'how hard can that be?', the Salchow proved to be an unexpectedly difficult matter.

I was first shown and explained the Salchow about 9 months ago. I think I needed about 2 or 3 months just to perform it in the most lame way that'd technically qualify, about as much as x = 1 qualifies for a math equation. The video is from April, i.e. more than 3 months on top. Today I can perform it somewhat higher and at slightly faster speed, but it still hardly qualifies for anything better than 'decent'. And while I hope it'll one day get to something I'd consider good, I'll probably never ever get to those crazy things like multiple rotations or anything even remotely close to what you can see on the TV, no matter how much and how hard I'd try. Do you still think that e.g. creating and maintaining a package is hard, compared to this? And don't even get me started on the next jumps ... the Salchow is actually easy. Try to think of this next time when you'd want to do something but would consider it too difficult (besides, take this from me, trying difficult things is actually much more interesting than the easy ones).

PS: Come to think of this, I've never thanked Danimo and Scott Wheeler, who happen to be ultimately reponsible for me starting with skating and having a lot of fun, as I'd probably never come across any such idea myself. So, well, thank you.

Some things are really really tiny details, yet they can be annoying in way. Something that's been occassionally bugging me is that fact that KDE uses the same wallpaper as KDM background, the splashscreen background and desktop background, yet depending on the screen resolution it may not be exactly the same background - during login the picture may stretch or shrink at certain points. The times when decent monitor screens had a 4:3 ratio are a thing of the past, starting with LCD makers making 5:4 "narrow-screens", then changing their minds and making 16:10 or 16:9 wide-screens. The choice of screen resolutions is not that limited either and that means that the wallpaper has to be scaled ... and that was the problem. Plasma has code to select how to do the scaling, KSplashX has code for that and KDM has code for that, and yes, you guessed it, it's always a different code. So unlucky resolutions get different wallpapers from different code. Since I actually spent some time in the past trying to make the login as seamless as possible, this indeed made me twitch whenever I saw it.

Seeing this again while testing openSUSE 11.3 made me finally spend the time to patch the openSUSE package to use the same selection code in all the three components. We really lack polish in so many places :(. But now it looks like the change is almost not there - there's just a progressbar and logo shown during startup and that changes to the desktop. With compositing enabled there would be also the fade-in animation.

Seeing that 4.4's KDM had no support for differently sized wallpapers, I was about to submit a copy of Plasma's code there when I noticed that trunk has some code for it. Of course, different from the rest again. Also, the login sequence is basically just lucky to be so smooth. The splashscreen is supposed to stay visible until Plasma is ready with its wallpapers and panel layout. And there is code in KSMServer to ensure this. And Plasma uses it. Yet it's apparently not used properly - during the first login, when there is more setup to be done during login, it's perfectly possible to see how the panels are set up. Well ... maybe in time for openSUSE 11.3 + 1.

You most probably have already run into this at least once. You use the computer, try to do something and you get an error message saying "sorry, application foo is not installed", "the required plugin bar is not installed" or similar. And that's it, there it stops. You have to find out what package the required functionality is in, install it manually and try again. Like if the computer couldn't ask "but maybe I can install that, do you want me to try?" and handle it itself.

And that's what my goodie for this openSUSE release is about. I've been examining a bit about what various parts of the desktop could do this and there indeed are some cases. For example, clicking in Dolphin on a file that has no associated application installed usually results in the "Open with?" dialog. And that dialog has nowhere in it the option "the application that can open it, silly". Especially given that if the installation medium is accessible (i.e. usually if the network connection is up), it's rather easy to find out the right application for the file and install it:

This specific case is actually a bit tricky. The file, example.kvtml, is a file with pairs of words or expressions that e.g. KWordQuiz can use for teaching (words for language lesson, for example). The problem is that technically the data is stored as XML and the mimetype (file types) specification has a concept of subclasses that is and in not useful depending on how you look at it. A C++ source file is a subclass of a plain text file, so you can edit it just like a plain text. Good. An XML file is also a subclass of a plain text file, so you can view XML as plain text. Good? I'm not quite sure on this one, since while XML is human-readable, any decent up-to-date XML is certainly not human-understandable anyway, so I fail to see the point. But, since .kvtml files are XML files, they are a subclass of them, and that means you can view them just like a plain text.

Good??? Probably not. They are supposed to be opened in an application that can show the lesson nicely, who'd be crazy enough to decipher it from the XML? Well, but that's the reason for the dialog looking this way, the above is what the dialog is trying to tell you. Sorry :). This should get eventually sorted out somehow in the mimetype specification, but for now I had to go with this.

The short version is: Just say you want an application that can handle exactly the file type, that's usually the right choice here. And if there are more applications that can handle it, you'll get a choice:

There is another, rather obvious case, where this can be useful. Amarok on its first start usually likes to complain about lack of support for certain well-known and widely used multimedia format and 11.3 will be no different. However, Amarok has also some support for solving this problem and has this dialog:

And that is where the new feature comes into play.

This time, however, there is the usual problem: The openSUSE distribution is not allowed to include the necessary support, because <a lot of ugly legal babble that causes headache>. Some distributions may try to include it and hope that residing in a country without such laws solves the problem. Or, even better, not having a load of money in bank avoids a lot of trouble too (what's the point of sueing somebody who can't pay afterwards, these merry patent folks don't do it just for the sports). That doesn't quite work for openSUSE, being supported by Novell, and I bet every big company has been already sued for much more stupid things than this, just in case it'd work out. So openSUSE simply can't include the support and can't even really tell you where to get it. As long as the world is the way it is, there can't even be any "install all I need" button in openSUSE. Sorry. That's the way it is :(.

So what happens in this case it that the required packages will not be found. However, there are many repositories for openSUSE not provided by openSUSE, and you can add the right one and try again (BTW, the URL in the link doesn't work yet, that will be fixed in time for 11.3).

Choosing to enable additional repositories will simply launch the YaST module for configuring repositories. And, as I said, it cannot point you "here" and tell you which repository to add (because, if nothing else, it doesn't know anyway). But adding a repository is not really that hard.

After adding the right repository it will proceed with installation. Again, the usual allmighty YaST. Nothing hard about it, and this part should be mostly automatic anyway.

There it is. As simple as possible (sigh) and now it's ready (but the dialog is actually right, restart is required for technical reasons).

There of course can be more places where this could be useful. The crash handler has already support too, so generating proper bugreports with full backtraces should be now much simpler as well. This is so far just experimenting with the feature and seeing how it works out, if it works well, even more can be added after 11.3.

Do you know this one?

Phoronix tested md5sums of ISO images of distributions. The winner was openSUSE, scoring e29311f6f1bf1af907f9ef9f44b8328b, which gave it a noticeable lead before second Slackware (b026324c6904b2a9cb4b88d6d61c81d1), which is quite closely followed by Fedora (9ffbf43126e33be52cd2bf7e01d627f9) and Debian (9ae0ea9e3c9c6e1b9b6252c8395efdc1). The difference between these two distributions, as you can see, is only very small. Ubuntu completely flopped in this test, achieving only 1dcca23355272056f04fe8bf20edfce0, which is surprising, especially considering that its previous release scored a very nice c30f7472766d25af1dc80b3ffc9a58c7. (source).

Ok, that's just a joke, but the sad part is, as somebody pointed out, that it wouldn't be really that surprising if Phoronix actually did something like that. And, probably even more sad, there would be people who'd really take it as if it meant something and started adding comments about how last openSUSE is pretty good, last Ubuntu is so disappointing, and Fedora and Debian are not really that different.

So take this from somebody who has already done a lot of performance work: Benchmarks, on their own, mean almost nothing if you don't understand them. Especially if they are seriously flawed (I mean, testing filesystem performance by doing CPU-intensive tasks? Hallo? Probably even FAT16 could provide the same results in those tests on an SSD.), but even if the results are useful numbers, it is still necessary to understand what the numbers actually say. I think I wouldn't even have a big problem forging a "benchmark" where KDE would get better (and correct) numbers than LXDE by finding a scenario that'd be twisted enough.

And even then, it is still necessary to keep in mind what is compared. Comparing the default setup of Fedora and openSUSE means also comparing GNOME and KDE, which you may or may not want, but if you compare the distributions this way, it is affected by differences between the desktops, and if you compare the desktops, it is affected by the differences between the distributions. And in either case, it may or may not apply to another distribution or another desktop.

Yet one more thing to understand is what is measured and how it affects performance as a whole. Ages ago there was a Dot article that also mentioned performance improvements to be brought by Qt4 in some specific areas, yet even now there are numbers of people seriously disappointed by KDE4's performance only because they thought that since Qt4 improves in some areas, KDE4 will get exactly the same improvement, regardless of how much these improvements matter for the whole of KDE4 or how much of KDE4 was rewritten when porting from KDE3. When I fixed Exmap to work again and did a little benchmark as a part of it, there wasn't really much more to it than to show that Exmap works again and that it is very easy to lose a lot of advantage by a simple mistake, yet people had no problems drawing all kinds of strange conclusions from that. Since making right conclusions is unexpectedly difficult for most people when it gets to benchmarks, I really need to remember not to just post numbers again without also saying what it means.

And, finally, there is still the question of other costs and whether it is worth it. Various KDE components often have resource demands, but then they are also often worth it. I mean, we all could still use TWM, or, heck, Windows 95, but seriously, how many of us really would? This, ultimately, is always about what works the best for you.

Those that were at either CampKDE or FOSDEM might already know, so for those this is a status update, for the rest: I've been working on a tool that makes it quite easy to create packages in the openSUSE build service, which despite the name can create binary packages also for other distributions than openSUSE. If you've ever gotten a mail asking for a binary package of your application or help with a compile problem, this could make your life easier.

For example, imagine Joe Developer, who has written his KFoo application, uploaded it to http://kde-apps.org and is now watching what happens. But, alas, instead of thanks and praise, what often happens is that the first comment is something like "I get this compile error, can you help?" or "Are there packages for Kubuntu?".

It may be quite easy for Joe to see that the compile error is caused by libbar-devel not being installed, but how is he to know what the package is called in other distributions? The same way, how is he to provide binary packages for distributions he does not use? And that's far from all things that can go wrong in such case - Joe may be running KDE workspace 4.4, but somebody may be still on 4.3, where the application would nicely compile and run, if only one #ifdef would be added to the right place. But will Joe really downgrade his installation just in order to fix that, and again each time he does a release of KFoo? And then maybe somebody else will try to compile it on openSUSE Factory, which already uses GCC 4.5, and will get compile errors because the latest compiler is more strict than previous versions and rejects invalid code that however compiles just fine on Joe's computer. And so on and on.

Joe, of course, is a smart guy (after all, he's written this great KFoo app that everybody wants to run if only they could compile it :) ). He can get the idea to use VirtualBox and install other distros he could care about, and test in all of them. The question is how long he'd be really willing to do that, since it certainly sounds like a lot of fun (and lot of disk space, and work). And that still means that all those potentional users would have to compile KFoo from source.

Maybe distributions would eventually include KFoo, but there's this tricky loop 'nobody uses it' -> 'why should a distro include it' -> 'no distro ships it' -> 'nobody uses it'. Maybe Joe gets lucky, maybe he does not.

Sometimes other people may provide binary packages for the distribution they use, so if somebody likes KFoo enough (and knows how to do it), Joe may find a comment on kde-apps.org pointing to this package and can add it to the list of packages to download. Except this may and also may not work, depending on how well those packagers keep up. Having a binary package of KFoo-0.3 when the latest source tarball is KFoo-1.5 is probably worse than no binary package at all.

So Joe can go back to the VirtualBox installations and try to package KFoo for all those distributions. But Joe is a developer, not a packager, so first of all he'd have to learn how to actually do that (e.g. creating a .deb is quite different from .rpm, and even .rpm packages for different distros are not created exactly the same way). Worse, he is a developer, and, honestly, developers just love packaging, especially for multiple distributions, riiiiiight?

Now here comes the openSUSE build service (OBS), which as already said is not only used for creating the openSUSE distribution, but also provides the ability to create repositories providing additional software, also for non-openSUSE distributions. That almost looks like the solution for all the above problems, doesn't it? No need to install the distributions and do the builds locally, the OBS itself will do the building. New packages would be available very soon after updating the sources in the OBS. And kde-apps.org has even direct OBS support, so packages can have direct download links there.

There's still the problem of actually having to know how to do the packaging, but that is exactly what kde-obs-generator should help with. KDE applications in general happen to be simple to build, and thus quite simple to package (in fact, compared to some other pieces of software, KDE apps happen to be remarkably simple to package :) ). So a lot of that could be automated. In the best case, creating a KDE package in the OBS can be now a couple of clicks in the web interface, few osc commands (osc is the CLI tool for OBS) and running kde-obs-generator in the directory with the source tarball. I've already tested the tool with some packagers and they even started using it for real, because even for experienced people it saves work.

I still consider the tool to be experimental and work in progress, but it's already pretty usable. Currently it can handle Plasma themes, KDM themes, KPlash themes, wallpapers and generic KDE/Qt CMake-based builds. It tries to automatically figure out all the needed build dependencies (which however means the list of mappings from cmake to package names for all supported distributions needs to be extended as necessary). Also kde-obs-generator itself is packaged using kde-obs-generator. The biggest thing I've built so far is the whole of kdeutils, that's of course not how something like kdeutils should be packaged, but that shows it can handle quite a lot.

So, in case you'd like your application to reach more of its posible users, you'd like to ease your testing, or you're just curious, the documentation is in the openSUSE wiki. I'd especially like to point out the tutorial, which is really step by step and includes also things like how to create an account for the OBS, so maybe even a monkey could now create a package (well, assuming it can read and write and is pretty bright for a monkey ;) - this still cannot be as simple as just hitting Enter repeatedly). If there are any questions or a problem, see the feedback section (mail the opensuse-kde mailing list, or just ping me (llunak) in #opensuse-kde on Freenode).

PS: I'd appreciate if people using other distributions could edit the wiki page on how to actually install the binary packages in some easier way than going to http://download.opensuse.org, navigating to the right .rpm/.deb file and clicking on it. It's pretty easy with openSUSE so I assume there must be something simpler on other distributions too, but I can't find it.

I have fixed Exmap, my still favourite tool to measure system memory usage, to compile with latest kernels, and also to work on x86_64 (the latter was a bit of guess-work, but I think I got it right). KSysGuard seems to be getting close, and with Exmap unmaintained by its author :( I don't feel like doing this forever, but for now, it's still possible to get exmap from my home:llunak:kernel repository. And as I don't feel like trying to do cross-distro kernel packages in the buildservice, those not using openSUSE are left with either trying to package it for their other distro, or pick out the patches from the .src.rpm .

While I was at it, I had just a little look at memory usage. Since I had done quite some comparisons of KDE3's memory usage with other desktops in the past, the first thing that came to my mind was doing that quickly again. As these days LXDE appears to be the new lightweight kid on the block, I tried that one, and also Xfce. Finally there's TWM, basically just to show the memory usage without any desktop. All of them are default desktops on openSUSE 11.2 for a new user with a file browser and terminal open, the only exceptions being adding a mixer to the default Xfce setup for a reason that will be obvious later and not using the nvidia driver. LXDE is from the X11:lxde repo, KDE version is 4.3.5 that'll soon end up in an online update. So, here it is (for those who don't want to find out what all those values mean, the most important number here is the 'Effective Resident TOTALS').

Of course, this is not really comparable to my old memory usage test, for a number of reasons, such as this being x86_64 machine, the setup being different, and so on.

It's interesting to note that LXDE actually loses to Xfce. That 'python' there is in fact GMixer. That really shows that you don't get lightweight things unless you check the setup yourself. And it probably also shows that you can get lightweight things only if also your expectations are lightweight.

It also shows that KDE4's memory usage is not as bad some some might think, although it would be nice if somebody would be bored enough to analyse it in more detail. There seem to be enough people bored enough to just complain about KDE4 performance but not do anything else, and this is actually pretty simple. Or do you need an Akademy talk for that or what?

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.