2

In GTK+, most if not all widgets are based on GDK windows, which are in turn each backed by their own X11 window, assuming one uses the X11 backend (Note that I'm not talking about toplevel windows, but about the window specific to each widget).

What is the rationale behind this? Toolkits like GTK+ support other backends like Win32, and it seems like just getting your toplevel from the window system and drawing / managing everything else on your own would be less of a hassle in a cross-platform setting.

5

...it seems like just getting your toplevel from the window system and drawing / managing everything else on your own would be less of a hassle in a cross-platform setting.

In a world where the lowest common denominator is a window system where there are only top-level windows that are just canvases, you'd be right. But things haven't worked that way for a long time.

The biggest thing any window system that goes beyond tiling has to deal with is overlap. It has to to be aware of where the windows are and how they're stacked to decide where to send input and where to place and clip output. Once that problem is solved, subwindows per widget aren't a problem because the same set of rules is applied to a deeper stack. With the window system able handle it, there's no reason for every client to duplicate that effort, even if it is in a library somewhere. Every window system of any significance that came to life in the last 30+ years has adopted this model and toolkits like GTK+ take advantage of the fact that X, Windows and Quartz all use it.

On the client side, unique windows per interface component makes a lot of sense, too. Instead of being left on your own to figure out what part of your code needs to service that mouse click you got at (280, 192) in your main window, you get an identifier for the window where it landed that can be used to match it with a widget and coordinates relative to its boundaries. Your interface components only have to understand themselves (dimensions, text color, text content, etc.) and don't know or care what's going on anywhere else.

Having invented parts of that wheel myself once or twice in the 1980s, I can tell you from experience that it's a lot of work, and I'm much happier letting the window system take care of it.

2
  • So it definitely makes sense for these systems. Is sub-windowing still a thing on more recent window systems like Wayland, or do Toolkits have to emulate it for those backends? – Fabian Knorr Sep 13 '16 at 10:46
  • @FabianKnorr: I haven't done any serious work with windowing systems in over 20 years, but my understanding of Wayland is that it pushes almost all of that work onto the client-side compositors in the interest of simplifying its own architecture. I'm steeped in the X way of doing things but could argue both sides of the debate over whether or not what the Wayland model does is good thing. – Blrfl Sep 13 '16 at 14:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.