Boost logo

Boost :

From: David Turner (dkturner_at_[hidden])
Date: 2004-03-03 12:35:14


> 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

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

> 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.

David Turner

Boost list run by bdawes at, gregod at, cpdaniel at, john at