[boost] Re: GUI library - another one

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