New toolkits

Posted Nov 6, 2010 18:17 UTC (Sat) by drag (guest, #31333)
In reply to: New toolkits by rleigh
Parent article: LPC: Life after X

GTK is portable. It's already running on Wayland and a number of other platforms.

I don't see how GTK is 'a thin abstraction over Xlib'. That does not make any sense at all given how even on X you can use GTK on XCB instead of Xlib.

New toolkits

Posted Nov 6, 2010 18:47 UTC (Sat) by rleigh (guest, #14622) [Link]

It's a direct consequence of its interface. Take the main base class of the GTK+ widget hierarchy, GtkWidget. One of the key object signals is "event" which has a single parameter, GdkEvent. The GdkEvent structure is a wrapper around the XLib XEvent structure.

While it's obviously a portable toolkit, all the other backends retain this interface. That is, the underlying design principles and constraints of XLib pervade the GTK+ toolkit, and cannot be removed without breaking pretty much all existing applications. So the Wayland backend (and all other backends) presumably need to synthesise "fake" GdkEvents which must by necessity be directly compatible with the XEvents which GtkEvent wraps. So irrespective of the backend, you're using a wrapper around the XLib API as soon as you use Gdk. Gdk doesn't even attempt to abstract many of the XLib data structures; it's pretty much a direct 1:1 mapping.

I am by no means questioning whether GTK+ (and other X toolkits) can be ported. I am just questioning whether the constraints upon their design as a result of their X legacy will result in a rather inefficient implementation compared with implementing a new toolkit which does not need to inherit this legacy.

Regards,
Roger