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!

Hardware enablement

Patches flying, and the results are nearly there.

Driver for the Apple Infra-red Receiver should soon be upstream (and a patch not to break LIRC setups), along with support for the Intuos 4 wireless tablet.

Ross merged patches in Gypsy which should allow for crappy serial GPSes to work, as well as the one on the Nokia N810 (and N900?), and the (even) crappy(er) ones that require a closed-source daemon and write to a FIFO.

GMyth dead?

Do you use MythTV? Do you use Totem?

GMyth, which Totem uses to access MythTV installations (watching recordings, and live TV) is dead upstream. Is anyone interested in taking over from upstream, and updating/maintaining Totem's plugin?

If I don't see any movement on this, I'll be forced to remove the MythTV plugin from Totem.

Code for cash: Summer of Code ideas

As you might know, the time as come to put in your applications for Google's Summer of Code project ideas.

There's a good bunch of ideas available on the GNOME side of things, but if you fancy helping out GNOME without working on GNOME, you might also like the ideas from FFMpeg, GStreamer, or BlueZ (some of it directly related to gnome-bluetooth).

And if you're into web development, we have 2 good ideas in the GNOME Wiki (See the Front-end for common web services and Collaboration server/client ideas).