Region panel

Yesterday, I finished working on a UI cleanup for the “Region and Language” panel in the control-center. You can see the results below. I'm pretty happy with this, though quite a bit of work could still be done, like allowing users to install “language packs” (fonts, translations, dictionaries) from the language tab, or integrating input sources in the layouts tab.

The layout before the separator are used by other users on the system

My favourite layouts, with the new contextual items

(and sans keyboard model selection)

infra-red remotes in GNOME 3

gnome-lirc-properties has served its purpose. It will probably carry on working on GNOME 3 desktops, but you won't be happy when it drags in GTK+ 2.x Python bindings, HAL or doesn't integrate into the new control-center.

But things have changed since gnome-lirc-properties was first written, and the way to handle IR remotes has changed as well:

• A large majority of receivers are now supported in the kernel using rc-core (né ir-core).
• Some receivers aren't supported (iguanaIR amongst others), and some need porting from pure input drivers to rc-core. Some functionality for the ATI Remote Wonder remotes is also not supported by the new drivers. If you're interested in working on this, drop a mail to the LIRC list.
• Mauro Chehab is making progress at propagating the key events from the kernel up to the stack to X11 applications. There's some patches in that direction on the Red Hat Bugzilla.

This means that:

• Event delivery would still need a broker in the session, to get to unfocused applications. gnome-settings-daemon can step in that role (and step out of the way when the application is focused, so the app can bring context dependent behaviour). gnome-settings-daemon already handle some of the more common multimedia keys in its media-keys plugin.
• The only configuration one would need to do is selecting the type of remote for the receiver, eventually tweaking the keymap for that remote.

So to write a replacement for gnome-lirc-properties that would fit into GNOME 3, one would need:

• A way to enumerate receivers on the machine
• A way to change the remote configuration (changing the keymap) for that receiver
• Eventually a way to tweak the keymap

This could all be handled through a D-Bus version of ir-keytable. If Mauro's patches reach X.org mainstream, then a kernel/GNOME summer of code project could be had for this work. Best to start writing some kernel patches, or laying some code if you want to get a headstart.

PS: For completeness' sake, there are also "pure" input devices that are remotes that wouldn't be handled through this. Those would need to be blacklisted in the input layer, and handled through rc-core instead.

YouTube playback will suck again

If you've seen the comments on this PiTiVi bug, you're probably already aware that YouTube/Google strongly disapprove of any breach to their terms of service.

We thought that Totem was living in a soft, gray, area by using YouTube GData API to do video searches, and then accessing direct streams that were of the quality expected by users, and in formats that meant out-of-the-box support for most Linux distributions (eg. using Web-M).

Turns out not. I won't make a whole scene about the way that this problem was brought up to me, but let's say that it wasn't the way I would have expected a corporation like Google dealing with things.

After a multitude of e-mails back and forth, I'm afraid that YouTube stuck to its guns, and I was repeatedly told about the "supported" solutions (embedding Flash was even proposed as a solution!).

So Totem will soon be playing your YouTube videos in crappy quality. Some of you with faster computers and better connections will be switching from full-HD streams to 176x144 videos.

If you want decent desktop integration with high-quality streams, feel free to "star" this GData bug report.