New toolkits

Posted Nov 6, 2010 16:46 UTC (Sat) by rleigh (guest, #14622)
Parent article: LPC: Life after X

While I find work such as Wayland very exciting and a logical step in supporting modern graphics hardware, I do wonder if we can take proper advantage of it with contemporary GUI toolkits.

While GTK+ is nominally portable, it's really just a thin abstraction over XLib; all the widgets are deeply tied into using X internals (GdkEvent/XEvent event handling, expose events and partial redraws etc., for example) which would be mostly redundant in an OpenGL context where widgets would be represented in a scene graph. While I'm sure it could be converted to use OpenGL, I do wonder how efficient it would be compared with writing a new toolkit from the ground up which used abstractions which map directly to what OpenGL can support efficiently, since [X]Window/GdkWindow drawing is basically tied to 2D rectangles. I understand Qt is part way there already with this, but I don't have the same experience with its internals.

New toolkits

Posted Nov 6, 2010 18:17 UTC (Sat) by drag (guest, #31333) [Link] (1 responses)

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