Today, a package was delivered to my house containing an item which I’ve been missing for a long time, years in fact. A second battery for my laptop. I’ve been working on various power management solutions in KDE in the past years, and they all had one problem: I couldn’t really test if everything worked with more than one battery plugged in. In that area, I always depended on others to help me debugging and fixing problems, not the ideal workflow, so some bugs have gone uncaught in the past.
Not anymore! Now I’ve got this second battery in the optical drive slot of my dear Thinkpad T60, I can immediately identify problems with displaying the charge rate of more than one battery, and I did. One bug displaying a wrongly formatted translation string in the battery’s popup has already bitten the dust, within one hour of delivery of the second battery, I committed a patch to the 4.4 branch and trunk of KDE SC. As far as I can see, showing the charge rate of multiple batteries basically works. I’ll probably find more room for improvement as I use this new setup, but for now, rejoice!
It’s out. Yes, finally. This release has been a bit of a bumpy ride. First thing was that we decided to do the release two days later, because on Tuesday (the date we’d initially planned), we already had KDE 4.3.4 scheduled. Then, yesterday, Dirk, our package-it hero had to struggle with some build problems in various modules.
Still, this is not a perfect beta. When trying 4.4 Beta1, you might find yourself without compositing effects. This problem has crept up in the last two weeks, and we’ve been only able to fix it this morning, too late for the beta. It turned out to be a problem of stricter capability checking, along with a change of the driver version string reported by mesa. Dirk said, he’ll roll another set of source tarballs next week, so you’ll get your compositing effects back. In the meantime, please focus your testing on other problems.
Allen was concerned about a bug that prevents KOrganizer from starting. We though about disabling KDE PIM for this beta, but in the end left it all in since we do want applications tested, buggy or not.
As you see, we’ve clearly shifted focus from get-your-features-in-mode to bugfix-mode. I’ve had a quick look at the statistics. In the past six months, we’ve closed about 18000 bugs in KDE’s bugzilla. Since the release of KDE 4.3.0, we’ve been able to close about 12400 issue reports. Over the last 7 days, we’ve closed about 900 bugreports. I think we should aim at 20000 closed bugreports until the release of 4.4.0 in February.
A “closed” bug means that a bug is either fixed, a duplicate of another bug that has been fixed, or that the bug cannot be fixed in KDE itself. This is the case for upstream (and sometimes also downstream) problems that really need a fix elsewhere. Some bugreports will also be marked “invalid” or “wontfix”, in which case the bug is actually not a bug (that happens :)). In any case, it means that we’ve triaged the bug and looked into it. Bugzilla is one of the important ways to feed back information to the KDE developers.
Of course you can help with the bug-hunting. Collecting data from a large variety of people, systems and usage scenarios is important to find corner-cases developers weren’t able to test or just didn’t think of. Please report those issues you run into! When doing so, for developers it saves a lot of work if you have a good look if your bug is already reported, don’t assume it is, but also don’t assume it isn’t.
When you’ve reported a bug, it’s helpful when you’re responsive to emails and check on your bugreport once in a while. We might need further information, there are often workarounds, and in some cases, it’s helpful for fixing a bug if we have short feedback cycles with someone who’s actually experiencing an issue to check further, or maybe ask to run a patch. The better your bugreport is, the easier it is for us to fix it.
Of course, KDE being Free Software, you can have a go at fixing some problem yourself, the source code is readily available, and if you know a bit about programming, issues are often easy to find and fix. In general, I find the KDE source code to be easily readable and understandable. In doubt, you can always ask another developer for directions, on IRC or one of the -devel mailinglist.
So, what’s so significant about KDE Software Compilation 4.4? Well, it’s a huge package of software, dozens of applications, a kick-ass development platform and an organic and usable desktop shell. One of the more noticeable changes that really cover all applications are probably the subtle transition effects that have been added to the Oxygen widget style and window decorations.
Another doublepluscool feature is the tabbed window manager. This new feature makes it possible to group arbitrary windows using tabs. You can now simply drag a window with the mouse wheel pressed onto another window and they’ll be grouped in tabs. The tabs are part of the window decoration, detaching windows works in the same way. Another very nice feature is the edge snapping. Dragging a window against the left or right border will put it on one the of side of the screen, exactly at half of the width. Dragging against the top edge will maximize a window. This way, you can easily tile (and group, with window tabbing) arbitrary windows.
I’ve stumbled across a nice video of some of the visual changes in KDE Plasma 4.4, you can find it here:
There have been quite some comments to my previous blog, among them some good points how to further improve the clarity of the battery applet’s info and control panel. I thought the best way to address this is with a patch, and a bit of explanation of those changes. So here’s the dialogue after a bit of further hacking on it:
Let’s look at the latest changes:
Bigger informational text, bold labels — Checking the charging state is the primary usecase of the panel, adding a bit of visual weight to the top section makes it easier to spot the information
Separator between info section and controls removed — As some people pointed out, the separator between the info and the control section resembles the brightness slider a bit too closely, and distracts visually
Configure button moved in line with the profile combobox — This is actually a very good point. It makes sense to put the configure button next to the profile combobox. The button actually leads to the profile configuration settings. It also makes it possible to …
Move Sleep and Hibernate buttons in line — Now we have two instead of three buttons in the lower section of the controls, we can actually put them in line and get rid of the large hole in the lower part of the dialog.
Aligned labels and controls horizontally — This last one is a label alignment bug in my code notmart quickly fixed after seeing the screenshot. Thanks dude! :)
I think that it works indeed better visually with those changes. The separation between info section and controls are better, the alignment of the widget overall is clearer, and as you can see, we’ve also saved quite some horizontal space. While it’s certainly not perfect yet, I think it’s a really nice improvement. Thanks to those who came up with the suggestions. I’ve just committed the patches to trunk, so they’ll be in KDE SC 4.4 beta next week.
On a sidenote, I had to order a new battery today for my beloved Thinkpad T60. The battery I’m using is, as you can see totally worn out. If you, dear lazyweb have suggestions how I can revive my (by now three) worn out accus, I’d be most grateful. I guess the constant plugging and unplugging of the accu and power cable isn’t the healthiest diet for this kind of hardware. Ow sacrifices … ;-)
Update: I’ve removed the percentage from the battery picture in the dialog, since it’s redundant (already displayed next to the “Battery:” label). Also, the dialog now reacts to font size changes on the fly.
The battery applet in KDE Plasma 4.4 has gotten some nice improvements. First of all, I wasn’t really happy with the layout of its popup dialog. It looked messy and didn’t scale well with bigger fonts. During Tokamak3 in September, I started improving this. To make it look calmer, I reduced the amount of edges widgets are aligned to. The previous version used nested layouts, which lead to widgets not properly aligned with each other. This creates a rather messy look. For 4.4, I’ve reworked the layout and reduced everything to only one layout and attached the battery in the popup off-layout in the top-right corner. I thought about using an AnchorLayout for this, but a simple setGeometry() to position the battery top-right would work as well, so I went for KISS. I also replaced the text on the "Configure Power Management" button with a tooltip, reducing visual clutter but keeping this handy in-context shortcut to easily get at the more advanced power managment settings.
The battery popup now resembles a FormLayout more closely, which should make it more consistent with how other dialogs in KDE are designed, so that’s a bonus in consistency. The two screenshots show the old and the new version of the applet side-by-side.
One wish came up more than once over the past months. Some (very vocal) users would like to see the battery showing the remaining time when it’s running on battery. Normally, the applet would show the charge percentage, which is a rather abstract number. (How long is 37%?) Now unfortunately, there’s no way to give an accurate estimation oft the time that’s left, since it largely depends on the usage patterns. You check the battery, it says "10 minutes left", then you start some app that exercises your CPU and disk and suddenly the machine goes into suspend after 3 minutes. Quite possible, and the usage scenarios and differences in modern portable hardware are such that there’s really no way to accurately predict the remaining battery lifetime. In the Plasma team, we decided that we rather not show the user unreliable information, since there’s only a very small group that understands that this number is almost black magic, and often simply wrongly reported by HAL. There’s well over 200 emails on that subject, mainly on the Plasma mailinglist and everytime this topic comes up we hear how much KDE must suck if this tiny little feature isn’t available. We’ve made this feature available in KDE 4.3, as a hidden config option (meaning that you cannot enable it using the configuration UI, but it’s there if you enable it in the configuration file. I had tentatively disabled this code during the larger part of the 4.4 development cycle to see if I’d get away with ditching it, and it didn’t quite fit in with the new layouting for the popup. Lately, the same discussion came up again, hopefully for the last time, since I submitted a patch yesterday night that brings the remaining time back (still as hidden config option, and that’s about as far as we will go). No, there won’t be a checkbox since I don’t want to confront users with information that’s most likely bogus and highly depends on what you’re doing at this very moment. As the option needs a power user to understand what this info really means (i.e. an estimation that’s completely off or not, depending on what your BIOS or ACPI subsystem reports), I think we can reasonable expect that adding a line to a config file is easy enough for those who really, really, really want it.
So, for reference, here’s how you get the remaining time display in the battery applet.
Install KDE Plasma 4.4, at least trunk from today
kquitapp plasma-desktop (to stop your plasma shell, as long as it’s running, it can’t pick up config changes, if you stop it after you changed the config file, it will happily overwrite your hand-made changes on quit)
Open your plasma-desktop config file, (mine is ~/.kde4/share/config/plasma-desktop-appletsrc, YMMV)
Locate the section for the battery applet, in the below example, you’ll find the plugin=battery line, choose the section that adds [Configuration] to the identifier. This section might not exist if you’re using default settings, in that case, it’s easiest to check the “show charge information” checkbox in the battery’s config (you might need to restart plasma-desktop for that, don’t kill it afterwards but use kquitapp). Then locate the showBatteryString= line and add another line in the same section:
showRemainingTime=true
Save the edited config file, restart plasma-desktop
The remaining time will now be shown if it’s non-zero (obviously bogus since the machine would be off then) and the battery is discharging. If in doubt, use “plasmaengineexplorer –engine powermanagement” to check wether Solid reports the remaining time at all, and that it’s non-zero. The remaining time could also be shown while charging, but this apparently isn’t supported by my setup, so I can’t test it.
Also during Tokamak3, Dario fixed a bug that would switch the display’s brightness back to 100% after it was dimmed because the machine had been idle. So if you’d set it to 50%, and it would then dim after some minutes of idle time, you’d move the mouse and it pops back to 100%, while it should go back to 50%. That’s fixed as well, and the patch has also been backported to KDE 4.3. You probably are already running with this fix.
Update: I’ve just committed a couple of changes to the battery applet and explained them in a follow-up blog
Earlier this year, while working on Lion Mail I wanted to be able to drag and drop references to items stored in Akonadi, I ran into some limitations we had in Plasma — in KDE 4.3, it is basically only possible to drop local files onto Plasma, with some exceptions. Think of dragging a photo from your file or image browser onto Plasma, and it offers to create a picture frame plasmoid on the desktop (or netbook, or whatever Plasma shell you use). or The underlying problem is the mimedata dropped either contains a URL or mimedata. The second case is clear, get the mimetype, find applets that can deal with it, add such an applet to the desktop and pass it the mimedata as arguments. Applets can specify, as parts of their metadata (actually an entry in their .desktop file) which mimetypes they support. For remote URLs, it’s not quite simple. It’s generally not possible to safely derive the mimetype of the data a link points to from its URL. The mimetype needs to be retrieved from the remote object (in most case, this doesn’t involve downloading the whole file, luckily, but just asking for the mimetype). As it’s likely a network operation, it can potentially take forever. We need to make sure we don’t freeze Plasma while waiting for the mimetype, so it has to be asynchronous. What we’re doing now when a URL is dropped, we start a KIO Job to retrieve the remote file’s mimetype, as long as the job’s running, we show a menu with a spinner, and repopulate the menu with suitable applets once the mimetype is in. The job retrieving the mimetype is then put on hold, and marked ready for reuse. This trick speeds up loading of the content from the applet, and the connection doesn’t have to be renegotiated. This mechanism works well now, I actually got it to work during the hacking sessions at GCDS, and merged it a few weeks later into KDE trunk/ to be part of KDE 4.4. Aaron has done a screencast showing this mechanism for wallpapers, it’s pretty neat.
(You can download an ogg version on blip.tv as well.)
The problem with this mechanism is that it’s not flexible enough for a couple of things I’d like to do, especially not for Akonadi, and also not for applets we want to create based on a specific web service, or anything else that you can safely derive from the URL. I’ve been thinking about a good solution for this for some time, but didn’t have high hopes to actually make it work in time for KDE 4.4, with the feature freeze looming in only a couple of weeks. On Sunday, I had told Steve (he asked for Akonadi/Plasma interaction, see below) that KJots notes (which are stored in Akonadi) should be drag’n'droppable between Kontact and Plasma (and possibly other applications), and that the way to go would be to pass around typed references to akonadi items by URL (basically akonadi: as protocol, the item’s unique id and its type wrapped into a URL). A lame suggestion in fact, since I knew it wouldn’t work. Then I figured if Plasma::Applet could just tell me which applets are suitable for a given URL (a mechanism similar to the mimetype-based finding of applets), we’d be peachy. Hacked up a patch for that and got it working just before I went to bed, had some good feedback the next day. So I went to clean up and optimise the patch a bit, had it review-boarded overnight and committed it this morning. Applets can now provide matching patterns for URLs. You put a wildcard (or a list of wildcards, useful if you want to cover some subdomains, but not others), in the .desktop file of the applet like this:
[X-Plasma-DropUrlPatterns]=akonadi:*
You can use the usual wildcard syntax, and put in multiple patterns (separate them with a “,”). This makes your applet automatically appear in the popup you get when you drop something onto Plasma. The patch weighed in at 35 new lines of code, quoting Aaron “impressive what’s possible with so little code”.
On an semi-related note, Lion Mail is getting better with every Qt release. Painting and clipping problems I had in scrolling with graphicswidgets seem to be gone completely when using Qt 4.6 snaps. Some automatic relayouting issues remain. Lion Mail’s Email QGraphicsWidget (the canvas-based equivalent to a “normal” QWidget) used dynamic relayouting pretty heavily, as it shows different parts of an email based on the screen space available for the applet. I’ll have to revisit some of this, it might be interesting to take the concepts and implement them using QML & declarative UI tech for that, and also making use of the Pure Awesomeness of steveire’s Elite EntityTreeModel for Akonadi. I’ll let him figure out how this works best for KJots first, though. :)
Today, a package was delivered to my house containing an item which I’ve been missing for a long time, years in fact. A second battery for my laptop. I’ve been working on various power management solutions in KDE in the past years, and they all had one problem: I couldn’t really test if everything worked with more than one battery plugged in. In that area, I always depended on others to help me debugging and fixing problems, not the ideal workflow, so some bugs have gone uncaught in the past.
Let’s look at the latest changes:
One wish came up more than once over the past months. Some (very vocal) users would like to see the battery showing the remaining time when it’s running on battery. Normally, the applet would show the charge percentage, which is a rather abstract number. (How long is 37%?) Now unfortunately, there’s no way to give an accurate estimation oft the time that’s left, since it largely depends on the usage patterns. You check the battery, it says "10 minutes left", then you start some app that exercises your CPU and disk and suddenly the machine goes into suspend after 3 minutes. Quite possible, and the usage scenarios and differences in modern portable hardware are such that there’s really no way to accurately predict the remaining battery lifetime. In the Plasma team, we decided that we rather not show the user unreliable information, since there’s only a very small group that understands that this number is almost black magic, and often simply wrongly reported by HAL. There’s well over 200 emails on that subject, mainly on the Plasma mailinglist and everytime this topic comes up we hear how much KDE must suck if this tiny little feature isn’t available. We’ve made this feature available in KDE 4.3, as a hidden config option (meaning that you cannot enable it using the configuration UI, but it’s there if you enable it in the configuration file. I had tentatively disabled this code during the larger part of the 4.4 development cycle to see if I’d get away with ditching it, and it didn’t quite fit in with the new layouting for the popup.