Mattias Clasen talked about the plans for intentionally breaking the GTK API for 3.0 in order to make it possible to achieve new features: XInput2, the drawing API, and changing theme engines without breaking applications. Emmanuaele Bassi jumped in to help Mattias Clasen with explanations. A goal is to make it harder for people to do deep hacks like the current string of abusive theme engines that will break from release to release and provide a feature-rich foundation for doing work correctly upstream.

The discussion moved on to client-side-decorations with Cody Russell which are already being developed on a side-branch. The work has a goal of being merged for GTK 3. This will enable GTK-support for things like Google Chrome's tab-in-window decorator and (finally!) GTK rendering the theme rather than being drawn by the window manager.

Cody said that he has be communicating with Trolltech to ensure that Qt does it in a sufficiently similar way in Qt that there won't be compatibility issues between Qt and GTK applications that provide their own CSD.

The issue was raise of what happens when an application freezes—how do you close it if the decoration is frozen in the same thread? Cody said that some discussion about extending the EHWM spec. to specify the area of the window where the close button is so that even when the application is locked, it's still click-able.

Another issue was raise regarding resizing the windows: there's a "jarring" experience in which the WM performs a resize of the buffer and then GTK CSD lags behind before the border is redraw to the size of the new edge. A solution would be to handle resize ourselves.

The rest of the discussion revolved around various use-cases and a discussion for application-specific API's for CSD: how to provide API's for a status bar at the bottom of the window that is drawn by CSD and provides the drag handle that is—perhaps—hidden on a netbook when maximized. Also, themes that attempt to make the transition from the toolkit to the border "borderless" may want to make regions of the menu area cause window dragging.

A question was asked about Glib 3.0. No plans are in the cards for Glib 3; there could be some fundamental design problems addressed but there doesn't seem to be anyone asking for it.

The discussion transitioned to performance with regard to animations and whether GTK could be made to provide high performance animations. There was some thinking that it's possible to extend GTK but the challenges that have been met and overcome in Clutter would have to be completely redone for GTK and it would be non-trivial.

Sponsored by GNOME Foundation