Dolphin screencast.

I’ve been playing around with screencasting software for some time. My idea is, to provide a series of screencasts showing off different aspects of KDE technology. I’ve now mostly sorted out the technicalities and concepts, so I started recording some test screencasts. For the screencasts, I’m using recordmydesktop. I’ve chosen a one means of distribution. Their web interface is nice and easy to understand. It offers a flash player, so it makes the content accessible very easily, but you can also view the Ogg Video version of the file, so it’s equally accessible for those preferring a Free format. also seems to have a reasonable understanding of licensing. They’re offering several creative commons licenses to choose from. I’ve chosen a relatively liberal license so the screencasts are easy to redistribute and use in other materials. Well, maybe not this first one, as I’m not yet a super hero in this authoring domain. To make things easier, I’ve not included sound. This pilot is about 10 minutes long. I’m using the fine Plasma notes applet to tell what’s going on, although I’m forgetting to scroll in the beginning, and somewhere towards the end, please bear with me — I guess that’s some sort of digital stage fright.

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!

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.

Lesson learned: Check your facts before you publically dissect the inner workings of something that is as complex as powermanagement for a desktop system and that you’re obviously not familiar enough with to judge whether this piece of software gets it right or not. I’m assuming that Matthew does know *his* stuff (his general points are pretty much all sensible). Unfortunately his arguments in the light of powerdevil’s actual implementation are all strawmen. I’d have expected a more thorough analysis from Matthew.

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.

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 +, 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 ;-)).