Networkmanager in KDE4.

Networkmanager is a daemon that keeps track of lower level bits on computers that have changing network hardware. It's designed to do this dynamically, and exchange information about status with a user interface that acts as configuration UI and policy agent. Networkmanager has gone through a large redesign between the 0.6 and 0.7 version, including the necessary API and DBus interface changes. Not without advantages though. I personally didn't really like networkmanager's behaviour in the past, found it too random, too much getting in the way. Networkmanager 0.7 is better in that regard, it doesn't drop my connection all the time for a start, it stays online while you log out and operates mostly within the bounds of what I deem sane.

One of the projects I've been working on over the last couple of months is the networkmanager plasmoid for KDE4. Will has put the infrastructural bits and pieces that are needed to work with networkmanager 0.7 into place. There is the networkmanager backend for Solid, KDE's library for interaction with hardware, but also all the different configuration interfaces for all kinds of network access.
During development of the networkmanager plasmoid, I've often used the GNOME nm-applet. It does the job quite well and is a reliable interface to networkmanager. Something I find a bit confusing is that it offers two context menues, one on right click and one on left click. I often find myself looking in both until I've found the option I've been looking for. This also has to do with a limitation of the whole systray interface, which seems really outdated when looking at how we usually do these things in Plasma. As a matter of fact, nm-applet uses the GNOME keyring, which reminds me that it would be nice at some point to share this functionality (i.e. have it uses kwallet on KDE and keyring on GNOME). Right now when using nm-applet, I've two password stores that I need to unlock after login. I've also tried some other 'wifi connection' UIs. One, I've seen in Windows was particularly bad. It would ask the user to type in a WEP key (the long versions, often), didn't offer any help doing this, but made it made it harder. You had to fill in the long HEX key twice, and both fields for that were password fields, so you can't even see what you're typing. It was just plain horrible. Quite a bit better is the interface of the iPod Touch (and presumably the iPhone). It does a good job on the input side (especially given that the user doesn't use a keyboard but the touchscreen). It does fall flat on its face technically though. First, support for WPA2 is lacking, that rules out access to the network at the university, and supposedly many others. Then, it often reports that it has established a connection when it merely logged on to the access point, but didn't get an IP yet. Since you can often connect to accesspoints (even encrypted ones) but don't actually get an IP address, that information is often bogus and it can be quite annoying being told you're connected, while you're not. One of my favourite wifi settings UI is the one shipped with Maemo. While it's nothing fancy, it gets the job done reliable and it doesn't confuse me.

So one of my personal goals is to not make all those mistakes in the interface for networkmanager in KDE4. We're not there yet, but progressing OK. Settings for wired and wireless start to work, as in "at least three persons on this Planet have ever been able to connect to a wireless network using it". It has UI glitches, it's not nicely streamlined for workflows we have in mind, the configuration interfaces are no beauty yet, and it has bugs, lots of it. It is in no way near release quality yet, more like an early Alpha. We're trying to have a first working version out within the next couple of months, hopefully in time for the distros that ship in spring. So the applet won't ship with KDE 4.2 we're planning to release it individually so you (or your distro) can grab it in the meantime. We're looking at putting it into KDE 4.3 then.
If you're interested in hacking on it or just trying it, the current code can be checked out from playground. For this to work, you need to have the libsolid code from kdebase/workspace/solid installed. There are actually two networkmanager plugins, one is for networkmanager 0.6, one for 0.7. The latter one is the one we're relying on. Yesterday, coolo started committing patches to the networkmanager plasmoid, scratching an itch. That's pretty cool given that he's one of KDE's oldtimers. A true honour to share code with :-)

[ Tue, 06 Jan 2009 02:13:16 +0100 ] permanent link

KDE 2008 fly-by.

The beginning of this year in KDE was marked with the tagging and release of KDE 4.0, followed up by the release event in Mountain View. KDE 4.0 has marked for the KDE community a stable base to build a kick-ass desktop and applications on. Over the past year, we see this effort paying off. Applications such as Dolphin, Gwenview and Okular are mature tools, powerful and userfriendly at the same time, speaking for the KDE4. With KDEnlive and Amarok 2.0 as their first KDE4 version, we see the more complex applications coming up. On the workspace side, new UI technology has matured, KWin's compositing and Plasma give you a very smooth ride as well.

The development platform is paying off, it proves to be a very extensible and future-proof platform, more and more applications are becoming available on Windows and Mac, KDE on OpenSolaris is getting closer to inclusion in the distribution, and we've seen KDE already available on FreeBSD. New applications written in Python have entered KDE, and scripting support for many applications is becoming available as well, in the form of services in Amarok and scripted Plasmoids for example.
The development platform appeals to be very attractive to new developers as well. At the end of 2008, we'll have welcomed 300 new developers in the project. The current activity in terms of commits to the KDE's SVN, the ongoing bug frenzy and general polishing of KDE4 desktop and apps is amazing.

On the organisational side, this growth in the KDE community and the increased attention from both users and the wider Free Software community, has been balanced out by the launch of the KDE Forum and UserBase to improve communication across a wider community. The formation of the Community Working Group has worked out very well and has come far in smoothening out how we work together. The wide acceptance of the Code of Conduct is another successful chapter in improving the collaboration.

The opening of the KDE e.V. office in Frankfurt and employment of Claudia has been an important step, and are leading to a smoother functioning organisation in many ways. In 2008, many developer meetings have been supported both financially and organisationally and two larger conferences have been held in Mountain View and Mechelen, which scored the record number of attendees.

So what's up next year? Personally, I'm hoping, actually being confident that in 2009 we see the rise of new technologies such as Akonadi, Decibel, integrated desktop search and the semantic desktop. I'm looking forward to seeing KOffice2 becoming available and maturing. Higher level concepts such as the Social Desktop will start to be integrated, and a wide variety of new and existing applications will make their way onto everyone's desktops and mobile devices.
More imminent, there will be the second KDE conference in the Americas on Jamaica in January, and a smashing Akademy during the Gran Canaria Desktop Summit in July.

It's been a smashing year, and we're not even done yet.

[ Fri, 19 Dec 2008 03:33:36 +0100 ] permanent link

Dolphin screencast.

So this first screencast walks us through a part of Dolphin's feature set. The different view modes, zooming functionality, tooltips, the cool selection mechanism (no ctrl-key!), shows how Dolphin integrates my USB stick and how you safely remove it, the Capacity indicator, the places, information, folders and terminal panels and how you can use them to make Dolphin fit your working habits. It concludes with a run through the configuration dialog. Enjoy!

[ Fri, 28 Nov 2008 04:49:51 +0100 ] permanent link

Re: Making sure we do power management the right way.

So Matthew Garrett dissects what he thinks powerdevil is doing wrong and gives a couple of point that in his view, power managemers on the Free Desktop aren't doing right at the moment. Let's have a look at Matthew's points (I'm paraphrasing here for ease to follow, hoping I'm not getting his points wrong):

• "Powersave is the wrong governor". First of all, Matthew assumes that the setting "powersave" will actually use the powersave cpufreq governor. Fair enough, the label offers it as powersaving mode. The CPU governor in use though is not the powersave governor, but the "conservative" governor, which indeed is an "ondemand" governor, meaning it gives you the extra needed CPU power when you ask for it. As its name says, it's slightly more conservative than the ondemand governor when scaling up. Matthew gets this wrong, but he's probably misled by the label we present to the user.
  The "powersave" performance profile does more than just switching the cpufreq governor, it can also control your display's power consumption (and in the future probably even disable animations all over the place so you don't loose any of these CPU cycles for eye-candy).
• "Thermal management is not the job of a power manager". True, mostly. Usually, it should be controlled by the BIOS. The default setting though is usually very conservative / safe. In general, we don't want users to fiddle with the limits (at what temperature should your CPU cooler start spinning?). Powerdevil doesn't offer such option, so Matthew will be happy about this item. (I don't see how Matthew gets to think that powerdevil does poke into thermal management settings, so I guess Matthews point was more a general one in the first place.)
• "Presentation mode". Something the app does indeed. We've discussed this on the hardware-devel list and came to the same conclusion. Again, powerdevil doesn't offer an option for presentation mode to the user because it's "an application behaviour policy" as Matthew tells us. I do agree. What Matthew is missing here is that PowerDevil manages those policies. It's in fact the central place to do so in KDE 4.2. Apps will tell powerdevil that a presentation is running, powerdevil will keep track of all apps inhibiting certain PM features (screensaver, dimming, suspend, ...), check other policies (e.g. "lock screen on resume?"). There's no "inhibit suspend" button in Powerdevil though. Downside is that we have to rely on apps actually setting this cookie -- which might or might not be more reliable than the user herself. So it might take some time until this feature in powermanagement on the Free Desktop works for everybody. (Until that time, you can switch to a power profile that doesn't suspend / screensave in the first place. All happy. :)
• "3d takes more energy than 2d". Might be true. From my measurements, however, facts are: a) KWin with compositing enabled does hardly spend "a significant proportion of the time on the GPU". (In fact, it sleeps most of the time.) and b) KWin in compositing mode does hardly need any more energy than when compositing is off. (Again, results of my measurements, those might be off. I'd invite Matthew or everybody else to provide additional data points so we can improve our default setting to optimize its behaviour further.) Users can of course easily check this themselves. Run powertop with compositing on, measure your CPU consumption, switch it off (alt+shift+f12), measure again, compare. In my tests, results have been in the 1% - 'hardly measurable' range. If that's different on your machine, configure powerdevil to automatically switch off compositing. If you're findings vary from mine, let me know and we can further improve powerdevil's set of policies.

I'd also like to thank Matthew for his input on these matters, and I'm glad it's not as disheartening or dramatic as he tries to put it. In fact, reading his blog, I'm now even more confident that we have something that is both, in its default setting a very sensible system to manage power consumption while not getting in the way of the user, and also very powerful for all those cases where machines are just a bit different -- so we're also set to deal with a great variety of systems and usecases.

[ Sun, 23 Nov 2008 17:15:08 +0100 ] permanent link

Embedded Linux and KOffice.

I'm on the train back home from ELCE (Embedded Linux Conference Europe) now. It was an interesting conference, not 100%, but quite free software-ish. Met a couple of nice people again: Adriaan (KDE + NLUUG), not quite surprisingly, Armijn (NLUUG + gplviolations.org), but also Will (KDE + Suse) who I've did a bit of networkmanager hacking with in between the talks, Shane (FSFE, FTF hero), Oliver Gravert (Canonical), Valer (NLNet) and others. Feels somewhat like home (which I wouldn't have expected from a mobile / embedded conference in the first place). I gave a talk this morning, which I found quite interesting myself (that's at least one person). I've talked about how to get KDE on a mobile device, starting with an explanation of the software stack and how those parts related to platform independence, moving to technical challenges when turning a desktop system into a mobile system (covering things like screen resolution and pixel density, input mechanism and the more limited hardware you usually find on mobile and embedded devices). People seemed interested although the room was not exactly packed. Also followed talks myself (Will's to begin with, giving me a bit more insight into Solid's networkmanagement stuff, quite useful if you're hacking on that ;-)). Ow, and fixed two layout glitches in battery and networkmanager applet, not bad.

Tomorrow, I'll be on the KDE-road again, going to Berlin to attend the KOffice sprint that's held in the middle of cocktailbars and restaurants (a.k.a. KDAB's office). But why? What do I have to do at a KOffice sprint? Well, one of the topics there is release promotion of KOffice 2.0, which I understand is due in the next months. I think KOffice is in a very interesting situation right now, and it's critical to position it nicely now so it'll have a bright future.
People that know me also might have heard me cursing about OpenOffice. Frankly, I don't see OpenOffice having a bright future. The codebase seems rather convoluted (about as many lines of code as the whole of KDE -- including KOffice) and because of its sheer size OOo is basically unmaintainable. Add to that what looks like a fork by the Novell team decided to publish as Go OOo, and a development model that's pretty much entirely much based on one vendor (SUN or Novell, depending on who you ask ;-)), so community involvement is apparently down to a minimum. With devices becoming smaller and requirements regarding the user interface becoming more central in the Free Desktop ecosystem, I just don't see OpenOffice providing a sensible answer to that.
Enter KOffice. It's free, it's lightweight, it's cross-platform, its codebase apparently is rather clean, in short it could very well fit into that mobile "niche" as use cases are more limited on those devices anyway. So what's needed to get KOffice in shape so that it becomes the serious contender? Frankly, quite some work still, in my opinion. First, it needs to work, a word processor, a spreadsheet application and a presentation program are the least I'd expect. so it makes sense to focus on those apps. Then, support for the most used standards, I know Girish is already working on getting OpenDocument support to work really well (absolutely critical IMO), but at some point, we'll also have to look at support for proprietary formats.

That said, I think there's quite the business case for a manufacturer seeking support for office documents in a certain product. So pitching KOffice to manufacturers in that market makes a lot of sense.

Then, there's of course the platform-indepence thing looming. KOffice, as many other KDE application will be available on Windows and Mac OS as well. How does that impact how KOffice sees and shows itself, and to whom? And how do we do end-user support? We certainly wouldn't like to burn credits by people that run into simple problems but just aren't able to find a solution to their problem or support in general (be it community support or commercial support).

Another interesting angle is the "OOo reinvents MS Office so we don't have to angle". KOffice's current user base is pretty small, so in turn, there are very little people who will complain when KOffice goes new ways (like Plasma did in KDE4), so I'd expect much less pushback when actually fixing the "Office UI", making it a sensible interface that's is a pleasure to use instead of something that drives me nuts the instant it starts (which is not really an instant in fact ;-)).

[ Thu, 06 Nov 2008 18:55:58 +0100 ] permanent link

Python Plasmoids.

Simon, our worshippalicous python bindings hacker came by tonight for a bit of hacking (he lives across the river from here, about 20 minutes by bike on a well OSM-mapped route. I was keen to get the new Python scriptengine Sime has just landed in SVN running so I can play around with Plasmoids written in Python.
The steps to get Python Plasmoids on running on your desktop are (assuming you have KDE from SVN installed): installing python, sip and pyqt into your development environment; building kdebindings, then you can build the plasma scriptengine located in kdebase. There are building instructions on TechBase.
Developing Plasma applets (which is pretty much the only thing you can do with the scriptengine right now, since there aren't any applets written yet -- except for the obligatory clock) is pretty easy from that point. You need to have a .desktop file containing some metadata and you actual script (which can be how ever long you wanted, it lands in contents/code/main.py and other .py's). How you include graphics and more is well documented on TechBase, so I won't repeat that here. To see if the scripting engine works, open the Add Applet... dialogue|Install new widget|...from local file. You should then see the scripting engine listed among the other options. In the future, we can make this part a bit nicer, installing and running and applet could be as easy as dropping it on the Plasma canvas and do the necessary security work. ll the needed information is already contained in the package.

This all is pretty new right now, and there are some rough edges here and there that need to be ironed out, but it basically seems to work at this point and is documented so we Pythonistas can get our hands dirty, with KDE 4.2 hopefully out of the Box.

The really exciting thing in my opionion about this is that with the scripting support, we can deliver full-fledged Plasma applets in Python. As they are scripts, it's easy to deliver them in a platform independant way through webservices such as the OpenDesktop, KDE-Look and others or share them with your friends in other ways (hi JOLIE!).

[ Sat, 25 Oct 2008 01:29:11 +0200 ] permanent link

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

Weblog Archive