Hi
I would add:
9. (really 0 in my view) It should use an extensive resource description schema or language (for widget properties, layouts and relations) that is either interpreted at run time or (though I like it less) compiled into code transparently to the user. This resource description should probably be XML-based.
I agree that this is a Good Idea.
An alternative for a lower-level GUI library is to _support_ such description rather than to implement it (be designed to interoperate well with different implementations). The danger
This is much better from a design point of view, and in fact the library I posted is well on its way to supporting just this: take note of window_base::spawn. The one problem I forsee with automatic deserialization is connecting the signals: because C++ does not really have an adequate metadata system, it will be necessary to provide some kind of signal-to-function dictionary. There might be a good metaprogramming framework that can achieve this; I don't know. Possibly judicious use of the factory pattern.
10. It should not attempt to provide its own abstraction of 2D graphics. Some level of portable graphics capability would certainly be necessary but it should be kept to a minimum (your requirement #1 supports this I believe). A portable 2D graphics API is worthy of its own library.
I've been thinking about that. On the one hand, you Really Need a drawing-area widget, but on the other hand, it just about doubles the size of the library. I like your way of thinking, but how to integrate this unnamed graphics API nicely with the gui library? There should be implementation-dependent hooks for this.
Also, speaking of (7) - in many cases it is rather hard to express dimensions in device-independent units such as points or millimeters. Display resolutions are still low enough to require us to consciously consider whether to use 1 pixel wide or 2 pixel wide lines, manually prepare icons of different resolutions instead of resizing the bitmap, etc. The "named units" approach may help.
Yes, I agree. As things stand, I use pixels to specify the padding around windows and between grid elements. Everything else is auto-sized and arranged. I think if the implementation provides reasonable defaults for padding, etc., then there will be no practical problems. Regards David Turner