Power management in Android's kernel

Google was going to be an interesting case of a large company hiring people both from the embedded world and also the existing Linux development community and then producing an embedded device that was intended to compete with the very best existing platforms. I had high hopes that this combination of factors would result in the Linux community as a whole having a better idea what the constraints and requirements for high-quality power management in the embedded world were, rather than us ending up with another pile of vendor code sitting on an FTP site somewhere in Taiwan that implements its power management by passing tokenised dead mice through a wormhole.

To a certain extent, my hopes were fulfilled. We got a git server in California.

mjg59

Restrained Life Viewer for Linux

Current (1.15.2_LL-1.21.6) binary distribution of Restrained Life Viewer for Linux is broken. The binary is compiled with an extra flag which is not in the settings file, which makes the client crash when trying to wear a blindfold.

Luckily this is easily fixed. The patch below makes you able to enjoy being blindfolded also in Linux.

--- RLV-1.15.2_LL-1.21.6/app_settings/settings.xml      2008-10-25 22:03:09.000000000 +0200
+++ /home/divide/games/SecondLife-i686-1.21.6.99587/app_settings/settings.xml   2009-03-11 13:58:29.000000000 +0100
@@ -12,6 +12,17 @@
       <key>Value</key>
       <integer>1</integer>
     </map>
+    <key>RestrainedLifeNoSetEnv</key>
+    <map>
+      <key>Comment</key>
+      <string>Toggles the RestrainedLife atmospheric effects restraint, needed for eg. blindfolds. (False means blindfolds work.) Needs a restart of the viewer.</string>
+      <key>Persist</key>
+      <integer>0</integer>
+      <key>Type</key>
+      <string>Boolean</string>
+      <key>Value</key>
+      <integer>0</integer>
+    </map>
     <key>RestrainedLifeDebug</key>
     <map>
       <key>Comment</key>

The sound of silence

From "The Power of Now" by Eckhart Tolle:

Every sound is born out of silence, dies back into silence, and during its life span is surrounded by silence. Silence enables the sound to be. It is an intrinsic but unmanifested part of every sound, every musical note, every song, every word.

It somehow made me think of John Cage:

Probably the most beautiful short I've ever seen

Signs
by mg02

(Via ^eirena.)

Snapshotting and cropping widget

I wrote simple Qt widget that is able to take an image of its own contents, and then crop it. (I use it with a video player widget to allow the user to take a snapshot of the video stream.) You can find it at the repo. It's not perfect, but it's what I need. Feel free to extend it, the mob access is open.

As an example (no code at all, all designer point-and-click), consider the following window:

Now if you click the "Snap" button (which is connected to the CropWidget's snap(bool) slot), the controls are no longer interactive (and are, in fact, just images of controls). You can use your mouse instead to draw a crop rect:

And then, by clicking "Crop" (connected to crop(), simple), get it... you guessed it ;)

Synaesthesia resurrection

Synaesthesia may well be the most beautiful and meaningful music visualization I've ever seen.

Unfortunately the project seems abandoned—it's twelve years old and last release was in 2005. As such it's a little bit hard to use nowadays; well, you can pipe sound in just fine, but what really lacks is the ability to record a video of the visualization.

This is especially important for me because I'm using a Polish Twitter-like thingy which makes it much more straightforward to embed videos than sound; every time I find myself wanting to share a song I'm listening to I have to find a video on YouTube, and when there is none, I feel compelled to share a synaesthesia video.

So I took the matter into my own hands and hacked together raw video output for synaesthesia. You can find the code at the repo; feel free to tinker in it, you may even commit anonymously (just use the mob account and branch).

I can now do
mpg123 -s song.mp3 | ./synaesthesia --width 640 --height 360 --output-raw 25 pipe 44100 | nice -n10 mencoder - -demuxer rawvideo -rawvideo w=640:h=360:format=rgb32:fps=25 -oac copy -audiofile song.mp3 -ovc lavc -o song.avi
and get a video like this one:

The only thing that needs doing is making it possible to visualize asynchronically. Currently it still generates the video in real-time while playing and this sometimes causes dropped frames (visible in the video as some hickups, especially at the beginning).

My share of shower insights: power to the artists!

KDE4 has made revolutionary changes in UI architecture, there is no doubt about that. But I can't shake the feeling that, while you can certainly see big advantages this brings to applications, all those KDE4 pillars aren't leveraged nearly as much as could be, in principle, possible.

Take Plasma, for example. The decoupling of logic and presentation into engines and plasmoids is perhaps the most powerful single idea implemented there. But what I see as the greatest opportunity it creates is left untaken: the decoupling makes it possible, in principle, for the artists to design plasmoids entirely by themselves.

Indeed, the simplest Plasma applets do nothing that couldn't be trivially designed graphically: see my own RSIBreak plasmoid (a simplistic prototype yet, sorry) for example. Yet, we still have the situation that the presentation logic is written in a programming language; even if it isn't C++ but something more human-friendly, such as Ruby or Python (having said that, I have yet to see a single useful plasmoid written in one of those) it still leaves out many if not most of the people that could design them on the mercy of developers, who often have more interesting things to do than code trivial UI handling code.

Even the more complicated applets, see the clock for example (you can't talk about Plasma without mentioning the clocks, can you?), could be done entirely in a language designers already know (even if not directly)—SVG. SVG is expressive enough to do every operation that is currently done in C++ code of analog clock plasmoid. But how to program graphically what operations map to which inputs? Why, telling by showing, of course:

The problem with current architecture is that we cannot easily modify SVG tree programatically, so we end up with having to use two languages to describe the interface: SVG for the static parts and C++/whatever for the dynamic behaviour and coupling with the engine. But, IMHO, most plasmoids' presentation could be described just by a smart mapping from engine data to SVG properties.

So, what do we need? What is teh masterplan? Well, first we have to have a framework in place—that's the easy part. First of all, we need a widget that is able to draw an SVG tree that we can modify. Then we need to devise language to describe mapping of inputs to SVG transformation—I'm pretty sure that existing SVG infrastructure for animation is well adaptable to that task. After that, it's just a matter of wrapping the mutable SVG widget with another one that draws the graphic transformed according to the transformation given input data.

The harder part would be making the "tell by showing" interface for the artists—but even without that, this approach has a whole host of benefits. Making a new plasmoid (using an existing data engine) would be just a matter of drawing it and coupling it to the inputs using a description—not programming—language.

This would enable theme designers to alter widgets' look completely—they would no longer be constrained by whatever design the programmer had in mind while writing the code; so that, for example, one theme could show, say, CPU temperature as a bar, while another could use VU-like meters, all that without changing a single line of code—without any additional code at all, in fact!

I'll confess that I'm largely inspired in this idea by Bret Victor whose paper Magic Ink: Information Software and the Graphical Interface I have once read and which sits in my head since and transpires to my consciousness from time to time. You should really read it in its entirety—it's full of innovative, revolutionary ideas and I feel that, with KDE4, for the first time in the history of computer user interfaces, implementing those ideas is finally feasible.