Given the recurring interest this topic incites, I think it is important to start by clarifying what people really mean by 'C++ GUI'. For the more practically-minded, it is a means to portably and easily write Modern C++ (TM) applications that use a graphical interface, while for others it is an occasion to Do It Right This Time (TM). Can they both be satisfied with the same API ? I believe this should be possible by making educated use of abstraction and modularisation. I'm a little reminded of the discussion around a socket / network / asyncio API, as I believe the situation is similar. This is because the methodological challenge is the same: what is needed is not a single monolithic API but in fact a set of interdependent APIs, and it is hard to draw a clear line between them. Therefor, I'd suggest we split 'GUI' into distinct modules and try to model each individually, keeping in mind that a) they all have to be able to collaborate and b) each may be implemented either in terms of a 'native' backend as well as in a OS-independent way. To get to the meat, here are the domains I think should be discussed individually: * Imaging Model =============== This module is concerned with low-level drawing primitives (2D at first, but may be extended into 3D). The associated vocabulary includes canvas, painter, graphic context ('GC'), path, pencil, etc., etc., you get the idea. * Event / Messaging Mechanism ============================= This module provides whatever it takes for individual parts of an application to exchange messages, both, graphical as well as other. Designing this module is particularly challenging if this is to be generic as some backends are rather constraining in terms of message types that can be sent / received. This module should be able to provide a uniform view on both input events ('button click', 'pointer move'), region management ('expose', 'resize'), as well as high level widget-related ('slider dragged'). * Region ('Window') Management ============================== This module is concerned with providing users with regions to draw to and receive events for, independently on what these regions actually contain. The associated vocabulary includes region, map / unmap, resize, stack, layout. While people may be inclined to think of these regions more in terms of windows, or even widgets, I believe there is good reason to keep these two concepts separate, even though in most cases there may be a one-to-one mapping between the two. (Imagine a situation where windows (which typically are screen-aligned rectangular regions) are not enough to represent regions, i.e. where you want to track stacked *shaped* graphics.) * Widgets ========= This is probably what most developers think of as 'GUI'. It's all those building blocks that have a certain style, behavior, and associated state, with more or less complex logic to keep 'view' (and possibly 'controller') separate from the 'model'. Again, I suggest this separation in the hope that it will facilitate and focus further discussion. I believe all existing GUIs support the above concepts, even though they may not be as clearly separate as I suggest here. In particular, depending on the architecture some of these aspects might be hidden, for example if the work is split into a display server and a client, where users only program the client application. As prior discussions suggest there are widely differing views on who should be in control of styling. Using different backends (or policies) developers / users can have more or less fine-grained control over these issues. A simple implementation of the high level APIs would be a slim wrapper around existing libraries, while for fine-grained control more work is needed. It would thus be an interesting exercise to see whether existing GUIs can be mapped back to the above modules I suggest. Regards, Stefan