From: David Turner (dkturner_at_[hidden])
Date: 2004-03-03 12:35:14
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