KDE4 in Linux User, away for a bit.

As we all know, one can never travel enough. In that light, Kim, the supermodel that shares this life with me announced to me that she'll be kidnapping me for a couple of days starting on Tuesday. We'll not be going far, just far enough to get away for a bit and recharge the batteries. (Actually we're running on solar energy and Port wine, but that doesn't make for a common metaphor, so there you go.)
But fear not, I've taken precautions for this scenario, and the guys over at LinuxNewMedia have kindly helped with that. In the last and the current edition of LinuxUser Magazine, there's a series about KDE4. It started last month with an article about Plasma that was the first part of a tutorial I've written. This month's edition features a longer article that explains all the easy 129 steps you can follow to get to your own Plasmoid. There's an example Plasmoids I've written for that article, it's called Dr. Ade, courtesy of Adriaan's promotion some time ago. (I'm obviously very proud of him -- well, maybe it's also the fact that we had this bet running. We've started off with one case of beer that I would give him. For every week I had to wait for his dissertation to be finished, he would give me one beer. Ade, you owe me two crates. No, I won't forget that.) But I digress. Next month's edition will conclude the KDE4 mini series of articles with an interview (again, with yours truly) about the future of KDE.
Me being away also means that you won't hear from me in terms of email, chat, blog or one of the other ways we communicate (did I mention the new KDE Forum?) as for that occasion I won't be taking my laptop, and I just refuse to write anything longer than a URL on those small devices that are taking over the lives of us geeks.
By now, you should have understood 3 points from this post: a) Don't expect timely replies to emails sent to me next week, b) If you plan to sneak anything by my eagle eyes that I wouldn't approve otherwise, concentrate on getting that done before next Saturday (instead of sending me emails), c) Go to your next store, buy Linux User magazine and start learning German (if necessary).

[ Mon, 13 Oct 2008 00:58:41 +0200 ] permanent link

Portugal in Fall.

I'm in Portugal right now, visiting Nuno to work on a top-secret commercial project for a couple of days. I think I've chosen the right time to come here. While the weather is mostly vile back home in the Netherlands (rain, grey, overall depressing), the sun still shines brightly here in Regua, in the Douro valley. Can't say that this way of working is a pain. While we're really productive, having good conversations, complement each other nicely (strategic bits: me, graphics and beauty department: Nuno), we also find some time to dive into Portugese culture.
Tuesday, we've taken the afternoon off to drive into the Douro valley, the region where all Port wine comes from. The cropping season is just beginning here, and the vineyards are starting to change their color from green to shades of yellow, brown and red. With the mountains here, that makes for beautiful scenery. Also the smell of fermentation is slowly coming up (that same smell you might know from your last visit of a wine cellar, if you ever did that). It's funny and amazing at the same time to read the names of the wine houses, most are actually known to me, and then you see their vineyards...
Some of you, my dear readers, might know that I'm a big fan of Port wine, so I'm also taking this opportunity to understand a bit better the circumstances of making this great product, the weather situation, geographical circumstances, but also food that goes along with traditional Portugese wine culture. Tomorrow, I'll be going back home, and next week, Kim has claimed a couple of days to visit Leeuwarden and Groningen in the South of the Netherlands, and to spend a bit of quality time -- we didn't have much time for that lately.

[ Thu, 09 Oct 2008 13:58:10 +0200 ] permanent link

Power management goodness: KDE 4.2 will suck less

... power. As Dario has already blogged, we have a great new application in kdebase, scheduled to be released with KDE 4.2 in january. PowerDevil is actually not an application in the traditional sense. PowerDevil delivers the infrastructure for power management in KDE. This means it'll notify you when your battery is running out, it dims your screen a bit when you're idle to save some battery life, it switches to a lower power consumption state when you unplug the AC Adapter, it automatically suspends, hibernates or shuts down when your battery is (near) empty, that kind of stuff. For a user, it's not a real application, but much more a service that handles some tasks for you and doesn't get in the way.

Technically, powerdevil is designed to integrate with KDE's platform-independant infrastructure. So while the actual tasks are very close to the hardware's capabilities, powerdevil is not bound to Linux for example. The code is very portable, thanks to the Solid hardware abstraction. Naturally, PowerDevil uses knotify to tell the user about anything she needs to know, fine-grained control about all notifications is available in the System Settings module.

PowerDevil consists of the following parts:

• A configuration dialogue in System Settings
• A kded module that does the background work
• A KRunner for command-line access to most functions
• A Plasmoid for quick access to some popular functionality

Thanks to the awesome work of pinda, you can drag the battery's pop-up control to the desktop and have it sit there as separate applet. There will be a button in the top-right corner in that case that moves this "extender" back into its original location (the battery applet's popup). Neat-o.

Wacky detail, as you can see, the popup also shows the battery. I've loaded another (simplified) instance of the battery applet there, so that's all animated and shiny. Thanks to the power of plasma's dataengine, all the "getting data code" is shared between those applets anyway. UI-wise, the battery-in-panel is actually a subset of the "battery-extender-on-desktop".

I've also done some performance tweaks to the runner (also in kdebase) that lets you control power management aspects. As we still haven't implemented an easy way to find out about krunner syntax (I usually check the source code :/), here's a quick list of things krunner + powerdevil now understand:

• screen brightness 80 to set the brightness of your display (between 0 and 100)
• suspend for various suspend methods
• power profile to switch to a different profile
• power governor for a list of CPU governors
• power scheme for different schemes (note to self: find out what the difference between scheme and profile is ;-))
• screen brightness (without number) to turn off and dim the screen

In other power management news, we've also come quite far. Various people (among them Lubos) have done an awesome job making KDE suck less power. I've done some tests over the last months. Around KDE 4.0, the machine caused 700 - 900 wakeups per second, idle. Most of that (but not all) was caused by an issue in xine when using certain functions in phonon. Right now, we're pretty much there. My idle system is down to around 100 wakeups per second, most of that caused by hardware (wifi, usb, sata, ...). Something the kernel developers are working on. KDE (plasma + apps) accounts for 5 wakeups a second, the first KDE app comes in as 10th. To put those numbers in perspective: 100 wakeups per second is already pretty low. Everything below it is probably highly optimized. Even in compositing mode, when you're not moving your windows KWin doesn't suck extra power. Good news for mobile KDE users. :)

[ Fri, 26 Sep 2008 04:04:04 +0200 ] permanent link

We are out of swordfish.

... which, in Greece is served as a main dish. So at a regular dinner, that's after the second Ouzo, which is both refreshing and the kind of fun that flushes your java-fried brain pretty thoroughly.
As Ade already blogged we're in Greece, just south of Athens (that's where "50" inside a red ring on a road sign means "120 km/h is a good average, you have to fiddle with your navigation system after all at the same time", at least in taxi drivers' minds, apparently) for a SQO-OSS sprint, but also where the waiter happily shows you the fish you're planning to have for dinner, and even gives it a name (in my dinner's case "Papadopoulos") on request. But let's try to keep the "We are out of ..." titled blogs void of sensible content ... (respect tradition!)
On a totally unrelated note, today's kudos go to Nuno for providing me with green, yellow and red variations of the Blue Curl wallpaper (the default KDE 4.1 one) they're in the slideshow plasma rotation wallpaper plugin and making this world a better place (did I mention that I don't have a real life? ;-)).
Concluding with today's geek survival tip seems appropriate: If your mouse cursor behaves in very weird and unpredictable ways, if you see context menues popping up seemingly randomly and if you just have a really hard time pointing at anything: *do* check your short's pockets to make sure you didn't tuck your wireless mouse in there. Worked for me.

[ Tue, 09 Sep 2008 23:14:50 +0200 ] permanent link

New Nvidia Beta driver: KDE4 flies, but has stability issues.

Last night Nvidia released a new beta version of their binary driver. This one has some new features, where especially a couple of RENDER pathes are now hardware accelerated. I've installed the driver on my desktop machine on a rather clean OpenSuse 11 and a 7600GS and tweaked it to enable to new feature that aren't on by default in this release (but are planned to switch on for the real deal). The performance problems I've had with switching desktop and apps are totally gone and KDE4 is flying like I've never seen it before. Switching tabs in Firefox is still slow, Konqi does it swiftly. I've set the following options in my xorg.conf. My Device section now looks like this:

Section "Device"
    Identifier     "Device[0]"
    Driver         "nvidia"
    VendorName     "NVidia"
    BoardName      "GeForec 7600GS"
    Option         "RenderAccel" "true"
    Option         "AddARGBGLXVisuals" "true"
    Option         "AllowSHMPixmaps" "0"
EndSection
    

Section "Screen"
    Identifier     "Screen[0]"
    Device         "Device[0]"
    Monitor        "Monitor[0]"
    Option "PixmapCacheSize" "20000000"
    Option "AllowSHMPixmaps" "0"
    SubSection     "Display"
        Modes      "default"
    EndSubSection
    [...]
EndSection
    

ERROR: The control display is undefined;
please run `nvidia-settings --help` for usage information.
    

Update: After some fiddling, I've got everything to work. The nvidia-settings issue was a local config problem, the lockups are only present when I forget to run nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1. I'm a happy camper now. :-)

Update: There's an even newer version of the beta driver available, try this one instead of the .68 or .69 version of the driver as it fixes a couple of problems with the beta driver and it's just more likely to work.

[ Wed, 20 Aug 2008 18:25:21 +0200 ] permanent link

that demo machine...

Wade brought me a new Mini-ITX motherboard for a demo machine we used to have in the boothbox (but which had one minor issue: No X, not even after lots of driverfoo.). So I've replaced the VIA Epia board with an Intel Atom one with integrated 945 graphics chip. KWin's compositing now works nicely on this machine, it's swift and I see no graphical glitches. The machine has a 1.6 GHz Atom CPU. One problem now is that the slot-in DVD drive doesn't fit nicely. I can squeeze it in, but as soon as I screw the cover onto the small desktop case, the DVD doesn't eject the disc anymore, caused by a slightly squeezed top of the drive. So I'll need to find a way to gain a couple of millimeters of space in that box (or stick a note under the case that you need to open the case to use optical discs ;-)). Also left to do is testing multimedia. I might need to install a couple of plugins there, and I didn't check yet if sound works at all. I'll see if I can bring it to Froscon this coming weekend (depends if the boothbox will be there, or someone to take it to the KDE office in Frankfurt. (Drop me a note in that case :).)

Otherwise, we have a nicely working demo machine, with KDE 4.1 and exampla data on it that should also be easy to maintain for some time. I've installed all the interesting things from KDE4, so we don't end up with not finding all kinds of applications and need to install them on slow fairground connections.

Yesterday, I tried to reinstall my desktop machine, a rather nice dualcore with lots of RAM and fast disks. It's got two 17" displays connected. Lately, Nvidia's drivers have caused me some headache there, making it just no fun to work on that machine. So I've been mostly using the laptop lately. I do miss the comfort of a good desk and chair though, so I've hooked up the laptop with one of the TFTs. I need to try the latest nvidia beta drivers, a posting on the NVNews board sounds promising, at least. Can't wait to try ...

People on #suse have been rather helpful in getting me better acquainted with the system. I found out that's it's apparently quite helpful to people guiding you to tell them in how far you need guidance ("I'm an advanced linux user, but just don't know the distro very well") helps to avoid a couple of unnecessary questions ("did you restart X after trying the driver?").
Ereslibre has apparently fixed the Konqueror toolbar issue, I've been seeing for some time, I'm rebuilding everything as we speak.

[ Wed, 20 Aug 2008 00:50:21 +0200 ] permanent link

Akademy Runners.

On the train back home from Sint Katelijne Waver, I've got the kate session plugin working, which I wanted to have still during Akademy. I've missed that personal goal by three hours (or I pinned it down by 20 minutes, depending on how you view it). I had written part of that plugin earlier in the week

[ Tue, 19 Aug 2008 01:08:18 +0200 ] permanent link

How to survive Akademy.

• The beer in the small bowls is around 8% - 9%, don't drink more than 20 of those.
• Have a water once in a while (you can drink the tapwater in the university building)
• Get foodtickets before you queue up for sandwiches, saves you a lot of time
• Writing a music manager / player doesn't save you from having mediocre taste in music
• When hung over, don't even try to play ping pong with Seb
• Lunchbreaks feel a lot like the Ministry of silly Talks
• Don't write long blog entries when there's a keynote coming up shortly
• Marble.

[ Sun, 10 Aug 2008 13:56:16 +0200 ] permanent link

Take a peek at Akademy.

Not much time to write long reports right now (attending the Plasma Frenzy talk, heading off to the social event in a bit), still managed to get some photos up. Feel free to use those in your coverage, if you need special permission or a larger version (I've got them in 12MP on my box), drop me an email at sebas kde org.

[ Sat, 09 Aug 2008 17:45:26 +0200 ] permanent link

Going wild with KDE 4.1 themes.

Now KDE 4.1 is out, I've played around a bit with different themes. I've installed the KDE artwork package, and a couple of themes via GetHotNewStuff. KDE's coloring system has seen quite a lot of love, as has Plasma's theming engine. The results are quite impressive, as you can see in the screenshots.

First off, a bright setup with full-width, pretty standard panel. The Plasma theme used here is Aya, I've made the window background colors a bit lighter, just for more intense shininess. Those bright colors also go quite well with the "Glassified" color scheme, but I found it lacking some 'whitespace'. The screenshot shows some integration bits as well, the context menu offers to install the package using Ubuntu's gdebinstaller. The GTK+ theme blends in nicely with the colors I've set up. (Without me even tweaking it).

The Norway color scheme combined with the Aya Plasma theme. I've made the panel shorter, centered and a bit higher. People seem to like it that way as well, though I don't understand what the fuzz about such panels is. It tends to create dead corners, and what's better than slapping your mouse bottom-left and typing into kickoff? The colors are nice and warm, and some utilities such as a calculator, online dictionary and calendar can be found on the desktop.

The wallpapers used here should be available with KDE 4.1 install, some might be in the kdeartwork module. The tools I've used for theming the desktop are the Appearance module in System Settings (especially the color pages). The widget style used in those screenshots is Oxygen, the Plasma themes vary though. Aya is especially nice and flexible, as it bases its color on the widget colors you can tweak in System Settings. I still have some garbage in the systray, unfortunately. It's not that bad all the time, on the upside :)

[ Thu, 31 Jul 2008 16:55:50 +0200 ] permanent link

Thoughts on innovation on the desktop.

While surfing around on Teh Intarwebs, I've read complaints from people that we're doing something radically new to the user. Some of those users seem to have problems with all that "radically new" stuff. Honestly, I don't think they have seen anything we *can* do yet. With KDE 4.1, we have pretty much implemented functionality that was there, made applications smarter, and polished the looks. Almost all of the work on the UI, especially in Plasma has been put into recreating functionality from KDE 3.5. What is so radically new to it? Having a shallow look, both -- KDE3 and KDE 4.1 have quite a similar interface. Panel with tasks in it, an application starter menu, a simple clock with a calendar, a virtual desktop switcher and the systray. Just about everything is in the same place where people using KDE 3 used to find it. And in 4.1, you'll have icon groups on your desktop that work just like kdesktop's filemanager, only a bit more flexible. Overall nice improvements, but certainly nothing radically new as a whole. That's probably as far as it can get with re-creating the traditional desktop. Nobody wants to create an exact copy of KDE 3 at this point anyway. If we would have wanted that, we wouldn't have started this journey that is KDE4.

Yet nobody wants to take away the traditional desktop from the users. That's why KDE 4.1 looks like it is. It's a relatively conservative traditional desktop. If you look at the KDE 4.0.4 implementation of openSuse, it's even very close to how KDE 3.5 looks like and works. Besides that, you have enough choice to run any traditional desktop around, wether that'd be KDE3, GNOME, XFCE, or whatever you like. And in August, we'll release KDE 3.5.10 for those that prefer 3.5. See, we're nice people, we're not abandoning 3.5. We don't want you to move. It's completely up to you. KDE 3.5 is rocksolid and works really well in many aspects. KDE 4 has not reached its full potential yet. You will be able to decide yourself when it's time to move to KDE4, if ever. And if you happen to fall in love with KDE4 applications, which is quite possible, they also run just fine in KDE 3.

Surely the developers do need some room for innovation and trying out new ideas. It would be strange if we kept adhering to all those traditions and copied 3.5. And it's why we created KDE 4 in the first place. Two years ago I talked with a Canadian friend on the phone about KDE 4 and Plasma in particular. The idea was back then to create a desktop that is backwards compatible with what people are used to, yet offers new cool stuff that gets you hooked. With KDE 4.1 we've probably reached this goal. A desktop that's pretty close to 3.5's functionality.

Regarding those relatively small adjustments we've made to the desktop shell, one could wonder what some people say when their filemanager and applications start dealing with information, rather than with data understanding relationships between information, people, ... and works with metadata and semantics, rather than a hierarchic filesystems. (that's what nepomuk might bring us at some point) What about when we start blurring the lines between the desktop, the network and other devices. Will people start freaking out then?

A couple of days ago, I read that 166 new SVN accounts have been created in the last 6 months, that's a lot of new blood. That's 166 people that plan to contribute to KDE codebase on a regular basis. And those are people that are obviously attracted by the direction KDE is taking.

So what will KDE 4.2 look like? Judging by what the Plasma team has accomplished in the last couple of months and the magic crystal ball, we might see some mighty cool new things. I'm certainly looking forward to integrated uiserver and Plasma notification applet, the concepts of detachable extenders and Plasma's ZUI integrated with KWin and generally made more polished.

I'm sure KDE 4.1 will be a blast, and if people still complain that it doesn't do exactly the same as 3.5, we can probably never get it right for some. I've personally always found KDE a friendly bunch of people that like creating cool and free technology together. Let's concentrate on just that. Happy hacking!

Props to Wade for the picture.

[ Wed, 09 Jul 2008 01:44:44 +0200 ] permanent link

Plasma while I'm away.

So without being able to have a look, Plasma is still progressing at an amazing pace. Last wednesday, before I left to Belgium for Rock Werchter I mailed Marijn (who is the student working on Plasma on Small Form Factor (SFF in Ade-language) my N810 so he can look into getting Plasma going on that device. Returning, I see a blog of his showing Plasma running on Maemo on the N810. Awesome. I'm looking forward to trying it and be able improve plasmoids for this formfactor. Being able to see your own code on a new device is also quite cool, I must say.

Next, as far as I can see, with consent of the release team, we managed to put one more new feature a lot of people wanted to see into Plasma in trunk/ -- meaning this will make it into the upcoming KDE 4.1 release. So now you can move applets on the panel. Yay!

In other Plasma-news, Dong Tiger has been working on support for Google Gadgets in Plasma, and it's coming along nicely as you can see in the screenshot. A couple of things still have to be solved, how to install them in the most intuitive way? The Google Gadgets are using a QWidget subclass that does rendering and input even redirection (by mean of Widgets-on-Canvas). So, support for many, many more widgets is coming up and Plasma seems to be becoming The Shell To Rule Them All.

Disclaimer: Support for moving widgets on the panel is going into 4.1. Support for running Plasma on Maemo will probably not be included with KDE 4.1, neither will support for Google Gadgets be. (Those disclaimers apparently are necessary to prevent confusion among those not reading developer blogs carefully enough.)

[ Mon, 07 Jul 2008 18:44:17 +0200 ] permanent link

Werchter

Just over two hours ago, I returned from Belgium where I was at one of those (watch out, sucky flash content with far too long animations) large European summer rock festivals, together with about 80.000 others. It was a blast. I've most enjoyed the Chemical Brothers' concert, which was late on Thursday night, they actually played until after half past three. Their show was quite "electronic" and very, very "phat", with lots of references to bands such as Kraftwerk("We are the robots, dum-tutu-dumdum!"). It was also good to see them not doing too much of their breakbeat numbers in the style of their early works, but coming up with refreshing new sounds, and using the stage and its rather nice visual equipment to its full extent. I loved their "Don't look back" which probably makes for an awesome soundtrack for Wade's "don't look back" series of pictures. I don't know how licensing sound for something like this looks like, though.

Other remarkable bands I've seen and really enjoyed were Soulwax, Moby, Duffy, R.E.M., Kaiser Chiefs (who probably won the prize for most drunk act). Radiohead did disappoint me a little, but I guess that's mostly due to their latest works being more "sofa music" than something to dance at a festival. So after four days of camping, cherry beer, music and pretty much void of shower, I'm back home, cleaned, took care of various pets including my own body and cleaned the house a bit. Now catching up on emails (which I probably won't manage to finish today, so hang on a bit if I owe you a message). I'm also updating my local installation from trunk/ right now to see what you busy bees have been up to.

[ Mon, 07 Jul 2008 17:43:17 +0200 ] permanent link

benchmarking XRender performance, how to file nvidia bugs

Blauzahl asks where to file bugs we encounter in the nvidia drivers. Last night, after my previous blogentry Fredrik told me he disagreed that it's hard to find nvidia engineers that can help with this kind of performance problems. It seems some hang out in #xorg-devel, and our planet admin Chris Lee is currently working on the NVidia Linux team as well. Fredrik pointed me to a benchmark that measures the performance of various XRender calls. Running it shows that most of the tests are very fast (1 - 20 milliseconds) or very slow (most between 8 and 16 seconds). That means lots of operations take 400 times as long as others. On my notebook's ati x1300 using the fglrx driver, I get results of 20 milliseconds for the 'faster' operations. Not a single test takes more than 2.5 seconds. So nvidia is faster , but only for some tests. Overall, ATI performs better in these tests. And then maybe those operations can be accelerated in the driver. xrenderbenchmark takes ~13 minutes on my nvidia 7600GS and 1:45 on my ati x1300, a fairly low-end laptop chip. In order to compile xrenderbenchmark, first "qmake xrenderbenchmark.pro" (make sure you use Qt4's qmake). Then run make, and xrenderbenchmark.

So if you encounter those performance problems, get Zack's benchmark and provide the data to the nvidia developers. The problems should be filed as a bug on the product xorg, component "Driver/nVidia (proprietary)" on bugs.freedesktop.org. I've filed the performance issues here, along with some my logfiles.

Update: I'm not the first finding out about this. Nice pictures showing the performance problems and lots of reports on the Phoronix forums. All reporting abominable 2d performance with NVidia graphics cards and drivers.

[ Fri, 27 Jun 2008 06:20:12 +0200 ] permanent link

How NVidia impedes Free Desktop adoption.

There has been quite some discussion about Free and closed drivers and documentation of hardware lately. Kernel developers demand open drivers, docs and development processes, NVidia refuses to open their drivers, arguing that the technical quality is not a problem, and that the driver contains intellectual property they wish to protect. Now ATI/AMD has shown that the intellectual property argument is at least not universally applicable to graphics hardware vendors. Let's also clear up a misconception about the technical quality of nvidia.ko: The NVidia driver is the single component in a KDE4 / Free Operating system stack causing us most of the hard-to-solve problems. In other words, nvidia.ko has grave technical shortcomings.

The most considerate article in my opinion is James Bottomley's essay on "Linux Graphics, an essay about three drivers". James puts NVidia's position into the context of Free Software developers and Linux kernel developers more specifically. I'd like to reiterate some of his points and provide additional insight into how this looks like from the point of view of a KDE developer. With NVidia just confirming that they won't open up their process, this sadly appears necessary. Let me start with some problems of NVidia's closed driver model:

• With an unclear licensing situation of those blobs, most distributors don't dare shipping nvidia.ko in their default install, spoiling the out of the box user experience that Linux is able to deliver otherwise.
• Performance and stability problems as we see them with KDE4 (and apparently Cairo-based rendering as well) spoil the user experience even more (see below).
• Triaging bugs caused by those issues is hard to do and takes a lot of our precious time. Even worse, NVidia doesn't seem to have the process in place to listen to those reports. nvforums seems to be the only way to reach NVidia people, it's hard to tell where to go with specific questions or technical issues. As a result, interchange between Free Software people and NVidia engineers leaves much to be desired
• Users suffering from those problems will likely just blame Linux and try to not burn their fingers on Free Desktop systems anymore, let alone recommend it to others.
• Not being able to help users with their problems caused by nvidia.ko is very frustrating, both for users who end up with a screwed system and developers not being able to help those users and still getting all the bad press.

• Temporary screen lockups. Suffering from this myself, I've done some research on the web. There were suggestions around that NVidia locks the system for some seconds when switching between powerstates. Disabling powermanagement through a kernel module parameter should have done the trick, it didn't do it here. Besides that, I would not feel comfortable with that, having a passively cooled video card and at least trying to not burn too much energy these days. Global climate change and local one (it's already quite hot in this room) getting in the way.
• Bad windows resizing performance. Resizing a transparent konsole window takes approximately 5 seconds here. It's slightly better with a non-transparent mode (and other applications), but still far worse than on my ATI card, and also far worse than in KDE3. Switching virtual desktops here (composited or not) takes some seconds, just enough to break my flow of working.

Reading comments of users over the Internet, there seem to be two patterns in the responses:

• "My system works, so I don't understand those complaining about their Freedom. It's more important that it works than that it's free."
• "It doesn't work, Linux sucks, I'll stick with Windows."

I can only guess about the reasons behind NVidia still being bone-headed as they are and not moving a bit. James brings up that they simply do not have the resources to support their product properly in a Free Software ecosystem. That seems the most logical explanation to me. Now resources in a company like NVidia have a lot to do with priorities, in turn, those priorities are often a function of market share. In this light, we end up with a self-fulfilling prophecy. Market share is kept low by Nvidia's poor support for the Free Desktop, which in turn makes them keep resources low for supporting those systems.

So how can we solve this problem of not being able to support our users properly? There are in fact a number of ways:

• NVidia's engineers could be more approachable to us.
• Nvidia's engineers could pay more attention to the world outside their forums and actively engage with relevant developers to solve problems
• We could recommend hardware from other vendors. Less nvidia cards around make for a smaller group of people running into those problems. Voting with your purse makes yourself a happier user and might, maybe, in the far-away future have people over at Nvidia read the writing on the wall.

As a Free Software developer, user and advocate, I feel screwed by NVidia, and as a customer, even more so. I would recommend not buying NVidia hardware at this point. For both political reasons, and for practical ones: Pretty much all other graphics cards around there work better with KDE4 than those requiring nvidia.ko.

[ Wed, 25 Jun 2008 18:05:47 +0200 ] permanent link

We are out of Maibock.

Random quote:

Whatever happens, don't tell anyone we had a pillow fight

[ Wed, 28 May 2008 00:42:42 +0200 ] permanent link

Your Rough Guide to Plasma.

So I've chosen to become Shane's Personal Plasma Steward. This in turn makes me much more aware of things, that I personally take for granted which aren't so natural (yet) to others. One of those things is "How does this thing work?" (for "plasma" as value of thing). Let me explain on a high level how you can use Plasma and make the most of it, starting with a default Plasma desktop.

Plasmoids and Containments

The Panel

The next icon (looking like either a desktop computer or a laptop, depending on the type of machine) is the devicenotifier. Plug in a USB disk and it will pop up a dialog that lets you open the device in Dolphin.

The next item on your panel is the pager. It allows you to switch between your virtual desktops. If you change the layout of the pager through the "number of rows" option, it will also affect the layout and animations that are shown in KWin's DesktopGrid effect -- (Switch on desktop effect, press [CTRL]+F8 to see it.) For bigger pagers switching on "Display windows icons" on the pager makes sense.

The taskbar is up next on the panel. It shows an area for all open windows on the current desktop by default. You can make it show all windows by checking "Traverse Windows on all desktops". Right clock on the window frame, choose Window behaviour, find this option in the "Focus" dialog. KWin's The expose effect offers similar functionality, it lays out all windows on the screen, start typing to filter the list, navigate with either mouse or arrow keys. The size of the text on the taskbar items can be set in Systemsettings | Appearance | Fonts | Taskbar.

Next on our default panel is the digital clock. This clock can display the time in different timezones. The sizing of the clock is half witchcraft, but you can partly influence it. The clock will adjust its font size to the area it is given by the surrounding containment (that's the panel in this case). If you choose to display the date, this date will be rendered using the "Small font" option from Systemsetting's Font dialog. The time will take the rest of the space. That means that for those who want it, it's possible to screw up the clock's display. On the one hand, the clock has to obey the user's setting for Small font (this setting reflects the "smallest readable font", by its very own definition, it simply does not make sense to use fonts smaller than that). So in the end, you'll choose yourself the amount of information displayed, and if that fits. If you want to display more information, make the panel larger or put the clock on the desktop where it can grow freely.

The rightmost Plasmoid in the default panel holds the systray, which is used by traditional applications as a dock. There's not a lot to say about it, other than "Plasma developers don't like the systray for its archaic architecture and want it to go away today rather than tomorrow". You probably know it from other desktop (even Operating Systems) already. It's basically a dumping ground for all kinds of things that you can better leave to their own plasmoids.

Cashews

Adding Applets

The Desktop

Right clicking on the desktop also offers you to configure aspects such as the wallpaper used, and the Plasma theme. Both actions offer to download new wallpapers and themes through KNewStuff.

With open applications, it quickly gets hard to see the Plasmoids on your desktop. The Dashboard gets those Plasmoids in front of you, much like the "Show desktop" functionality you're used to from traditional desktops.

KRunner

If you want to know what's going on on your system, there's the "Show System Activity" button, giving you quick access to a list of windows and processes, with options to monitor their output and kill processes.

"Activities" or the Zooming User Interface (ZUI)

That's it. Hope some of you understand Plasma better now, and that this blog helps those that feel lost initially do a little less so.

[ Tue, 27 May 2008 15:55:23 +0200 ] permanent link

GTK themes are fine again.

Two days ago, I've blogged about the environmental variable that sets the correct path to the GTK theme was broken. This made GTK apps use the default theme, which looks rather clunky. Yesterday, Kevin Kofler and Rex Dieter committed a fix for this bug. Rocking, dude! :-)

[ Sat, 10 May 2008 22:28:19 +0200 ] permanent link

Are we breathing in the same rhythm?

Tom and Aaron discuss timing and release schedules, and development cycles. Aaron talks about trunk/ and freezes therein should follow a natural lifecycle. This assumes that the whole KDE community lives and breathes as one individual, synchronised and all. So a development-and-release-cycle forces all developers into one rhythm. Everyone has to follow this one release rhythm. It's a good idea, but I think we should also make the lives of those easier that choose another breathing ryhthm. There are a couple of things to consider here. The most obvious being that we need this flexibility anyway. We rely on certain release mechanisms and interface stability policies in other projects as well. (We partly solve this problem by providing abstraction layers, think phonon and solid). Now the interesting case is that Phonon, which is new in Qt's 4.4 release is also provided by Qt. Phonon now breathes in a 9 month release cycle in Qt, and a 6 months one in KDE. So one could argue that it's a smart idea to breathe in the same rhythm as Qt does. We could follow up every release of Qt with a KDE release.
This does not solve the initial problem I think, which I think is "different parts of KDE have different heartbeats". Neither Tom nor Aaron have really questioned the way we currently deal with SVN before releases, so I'll put on my shiny pink asbestos suit and do it.

What if we never froze trunk? Others (such as, incidentally Qt) have no freezes in trunk/ and it seems to be a popular and well-working development style for some. When a release enters a freeze, a branch is created that will be stabilised towards the release. trunk/ at the same time stays open for feature additions. The Golden Rule is "You don't break trunk/ (this is what branches are for)".

(For those not too intimate with development schedules of KDE: trunk/ is frozen roughly 2 months in advance of a release (supposedly every 6 months). After the actual release, trunk/ is opened again for new features. Features that take longer than the allotted time be developed in a branch and moved into trunk/ "when they're ready, but not during freeze".)

The obvious downside of this "It's always summer in trunk" is that you need to spend extra efforts to get people to stabilise, i.e. working in a stabilise-branch rather than in trunk/. It needs more discipline, and probably puts some extra weight on the shoulders of those who simply care about good KDE releases. But as we all agree, SVN sucks for branching and merging. So right now we make it hard for people to work with different branches (stable/ and trunk/). It would allow those that need more time to do their thing to stay in sync with latest features. Basically, it would allow for different rhythms in the community. As this community grows and becomes more diverse this might pay off in the end.
New tools are on the horizon as well. Distributed version control systems allow for a more flexible way of sharing code between peers.

The thing is that we cannot really choose, people are using git anyway. And after having used it for a bit, and git-svn to interact with svn, I have to say that it makes a lot of things much easier. For one, it doesn't force the commit policy of the project ("don't break trunk" maybe ;-)) on yourself or your team, and it makes it easy to share code with others. That might want to work one a feature (or some surgery) together, but others (those that don't want to be affected by this surgery just want their desktop to work. Now imagine these peeps, just start developing features by sharing a number of git trees and committing features to trunk/ when they stabilise, i.e. presumably don't cause regressions. It also nicely solves another issue we had recently. Rafael needs some time to finish Goya (have it API reviewed by Kevin ;-)), but Jeremy already wants to use this feature in GetHotNewStuff2. Those three share a "review" branch, which is merged when everyone's happy (after having been announced on kde-core-devel. (Imagine integration of some sort of peer review system, like review board with this branch!). This development style can partly be tested by a subproject, of course. This subproject can then track trunk/ from SVN and develops features in a distributed way, probably with another branch as master that sits on top of it and tracks. It's not really a technical problem, after all, the tools should support the natural way of breathing for the community. For git in particular, I see the steep learning curve as one of the major show-stoppers right now. It would, at this point simply make the barrier of entering a project much higher, which is not a good thing. With distributed source code management, the question "Which one is the authoritative copy?" becomes a purely social thing. In the SVN case, it's always the SVN server, in the DVCS (OMG!) case, it's "who you trust", that would be the version we publish via SVN.

Interestingly, the KDE's Internationalisation people already work in a distributed fashion. In the Netherlands for example, Rinse collects translations; that are sent to him by the people in the translation team he reviews them and commits them to SVN.

Does this whole mess of an idea also contain a solution for "synching downstream"? One of the reasons why the Release Team initially decided to adopt 6 months releases is to make it easier for downstream (distributions, for example) to ship a recent version of KDE. The thing is that those distributions also have different heartbeats, OpenSuse comes 8-9 monthly, Fedora comes 6 monthly, others as well. Now we're trying to sync with upstream, in different heartbeats and downstream in different heartbeats. Right now, we have the unfortunate situation that we're just too late for OpenSuse 11 (which is really one of the symptoms of "heartbeats out of sync"). At last year's Akademy, Mark Shuttleworth brought up the idea of synching release over the whole Free software stack. While this is a nice vision, I do not see this happen 'globally enough' so that it really works. The trend in the Free Software world seems to be to move to a more distributed way of development.

This "we all breathe synchronously" might be one of the things that ties us together. We've seen this a lot in the time up to 4.0. That was where we as a community acted as one and lifted KDE from 'utterly broken' into a releasable desktop. In KDE 4.x, things are fundamentally different. With all the new frameworks and libraries solidly in place now we we want this to be a stable platform for a long time. That means we develop features on top of it and fix bugs in the infrastructure and extend it - not break it. Basically that's the "Binary Compatible until KDE 5.0" promise.

Moving from one, proven style of development to another is something we should not take lightly. On the one hand it would help us solving some scalability challenges in the community (such as too many different people, expectations, needs for their product and whatnot) and adopting new styles of collaboration in a community where you're free to share.

Things such as new ways of working together and the ever more diverse community's needs, expectations and lifestyles are not something we can ignore. We need to constantly look at ourselves and our environement and think about how we can improve it. Probably not one big step ("starting tomorrow we never freeze trunk again, promised") but hundreds of little baby steps.

[ Sat, 10 May 2008 01:05:19 +0200 ] permanent link

Hideous GTK themes in KDE4 sessions.

For some time, GTK apps running inside my KDE4 session would not pick up their theme properly, making them look hideous in their default theme. I'm using a small wrapper script (/usr/local/bin/startkde4) to get my KDE4 desktop up and running. Since I've put the "unset GTK2*" line into the script, GTK apps pick their theme again:

#!/bin/sh

export LD_LIBRARY_PATH=/home/kdedev/kde/lib
export KDEDIR=/home/kdedev/kde
export PATH=$KDEDIR/bin/:$PATH
export KDEHOME=~/.kde4

unset GTK2_RC_FILES

. /home/kdedev/kde/bin/startkde

Hope this tip keeps someone from tearing out hair. :)

[ Thu, 08 May 2008 12:58:09 +0200 ] permanent link

Weblog Archive