More on remotes and receivers

After receiving a load of new remotes last week, it was only fair I hacked on gnome-lirc-properties and fixed a number of the long-standing bugs, and release gnome-lirc-properties 0.5.0.

So, what happened

Before the 0.5.0 release, we had a very small number of remotes and receivers combination declared, and unless you owned a receiver and remote that the developers did, you had to select your receiver/remote combination by hand.

Johannes Schmid fixed half of that problem by creating a script that'll go through the lirc sources to add all those remotes to our remotes list. I fixed up a number of bugs, added quirks, and support for parsing user-space drivers.

With that, we went from around 10 remotes/receivers combinations to just short of a hundred.

What's next

ir-core work is ongoing in the kernel, and will provide drivers for a number of receivers with a default keymap. That means that things will work as soon as you plug them in.

A number of receivers also already have input drivers, one level down from ir-core, and work out of the box, such as the ati_remote and appleir drivers.

As we can receive events from the remotes, we just need to funnel them to the desktop. That'll be the work of lircd in the short-term, until XKB2 shows up.

Can I help?

Sure you can. Plug in your receiver, launch gnome-lirc-properties and report whether the receiver is not auto-detected, or whether no remote is selected by default. You can also get me one of the listed remotes on this Amazon wishlist :)

My new toys

Thanks to Openismus and Fluendo for sending me 7 new remotes. I guess it means I need to start helping Jarod make all those remotes work using the input layer now :)

And dark themes for apps are in GTK+

Another week, another GTK+ feature. This week's feature is probably easier to implement for applications that would require it, but the uses are also more far-reaching.

Before

After

What does it mean for me, application developer?

If your application matches the type of applications that would benefit from having a dark theme, please try it out. The 3 lines patch is easy to add to existing applications.

You'll most likely want to switch to using symbolic icons as well, for most of your UI, so that the icons show in the expected colour when a dark theme is not available.

What does it mean for me, GTK+ theme designer?

Either you keep your theme as-is. Then all applications will use that theme. This is most likely what should happen for Accessibility-related themes.

Or you create a "gtkrc-dark" file in your theme, at the same level as your gtkrc, and make it dark (not a bit darker like the bad example above, but real dark). Test it out with gtk-demo's “Application Window” demo.

By the way, you might want to update your theme for GTK+ 3.0 at the same time.

Client-Side Window Decorations and misconceptions

This morning, my RSS reader was full of news with links to Mark Shuttleworth's blog about Canonical's idea for windicators.

The problem now is people conflating Canonical's own design decisions (most of which I don't agree with, except for the case of netbook UIs, but that's not the point here) and Client-Side Window Decorations support.

Martin Gräßlin's blog lists a few things that you would lose if we were to use client-side window decorations. Most of them are just wrong:

• Consistent behavior between all applications no matter if it is a Qt or a GTK or $Toolkit application: How can you say that when there's no agreements on the implementation yet? Of course Athena widget apps will look different, they already do. As long as the theming and behaviour is known and agreed upon, there's no reasons why it should happen. It's just a bit more complicated because you would have cases where the Window Manager would behave differently from the toolkit. All those are solvable, and old, unmaintained toolkits will not integrate.
• Window Tabbing (KWin specific): Why would that be impossible to implement? You'd just need help from the toolkit to do that.
• Window rules like always show a close button even if the window is not closeable: Working around broken apps? Fix your apps...
• Accessibility features like big border and button sizes for all windows: Certainly not. It would even mean that you wouldn't get a disconnect between application and window manager implementing accessibility features.
• Easily changeable window themes: Why wouldn't they be easily changeable? That's highly dependent on how the theming is implemented in toolkits. I guess it would be the case if you had a half-hearted implementation.
• Shadows which are part of the theme (KWin would not paint shadows for a client-side window-decorated window): Why not? If KWin knows that the application is drawing its own decorations, it could draw the shadows, or you could make the application's toolkit be aware that it needs to draw the shadows. Either way, it's not impossible to implement.

There also doesn't seem to be a list of thing you'd end up winning:

• Tear-free window resizing (when the client is doing the resizing, with a proper resize grip for example)
• Better integration of resizing within applications (say "zooming" when going to fullscreen
• Proper way to do tabs in titlebar, a-la Google Chrome
• Window-as-a-document/object (see the tab interaction part of this Empathy UI review, which would enhance the integration between applications and file managers)

And that's just the things I see myself as winning. There's more technical details on the GNOME Wiki.

Update: Got my knickers in a twist over Client-Side Windows vs. Client-Side Window Decorations, fixed up links and text.

Deinterlacing, now in Totem

Totem, in git master for GNOME 2.32, has support for deinterlacing video streams, thanks to the work by Sebastian Dröge. You'll need gst-plugins-base from git master to test it out for now.

Free of charge, you'll get Philip Withnall's work on not blocking the interface when parsing playlists. This should make Totem feel more responsive overall.

Symbolic icons support in GTK+

The design

Discussed as part of the GNOME-Shell design plans, and at the Usability hackfest we had in London earlier this year, we wanted to have icons that would only draw attention to themselves when needed. Unlike what Mark proposed, we wanted to use the theme colours and sizes so as to avoid problems, for users either with or without a visual impairment.

The tricks

To load and theme the icons, we use a CSS style-sheet, with the "!important" keyword, overriding every colour in the SVG file itself. Here's an example of what it might look like.

The second trick is using the tray's colours for GtkStatusIcons. Matthias has more X-fu than me, so using X11 atoms, we export the colours we care about for the icon from the tray, to the out-of-process status icon. Seeing that the shell might not end up using status icons, and that the panel would have the same GTK+ theme as the rest of the desktop, it might not be quite as important for the long term.

Building the icon theme

Jakub updated the instructions on what it took to create the symbolic icon theme, along with some explanations of what's necessary to allow the recolouring.

To test out your created icons, you can also use the SVG snippet above, modify the colours, change the file path for the xi:include, and open the SVG file created with eog, or another gdk-pixbuf powered image viewer.

What does it mean for me, GTK+ theme designer

We chose to only export 3 colours for use by the icons, one warning ("orange"), one error ("red"), and a positive feedback one ("green"). Those are named colours in the GTK+ theme, and you can use Jakub's commit as an example on how to add support for those in your GTK theme.

The main part of the icon (the usually white, or gray-ish bit) will use the text foreground colour for drawing. This means that dark-on-bright and bright-on-dark themes should work out of the box without having two separate icon themes (as was done for Ubuntu's latest release).

What does it mean for me, application writer

Many of the GNOME desktop components already had bugs filed against them, to start using symbolic icons when available. First, review your icons, and see whether they match the use cases mentioned in the design documents. Check whether an icon exists for your application in the gnome-icon-theme-symbolic git repository. Make a patch against your application (example patch), and file it in a bug.

Then, drop by the #usability channel on GIMPNet IRC, or drop a mail to the usability list and ask for your patch to be reviewed.

Testing it out

Just like the famous quatre-quarts, 4 equal quantities of:

• libcroco from git master
• librsvg from git master
• GTK+ from git master
• gnome-icon-theme-symbolic from git master

Sprinkle with your favourite application for testing, or use gtk-demo.

Thanks

Hiroyuki Ikezoe for his librsvg and libcroco fixes, Jakub, Hylke and Lapo for their work on the symbolic icon theme, and Matthias for his original GTK+ patch.

And my icon turned itself into a symbol, *shting*

A few bugs to kill off before symbolic icons support is in GTK+. But we have some screenshot action for it!