[boost] Re: GUI library - another one

From: Max Motovilov (max_at_[hidden])
Date: 2004-03-03 13:15:42

"David Turner" <dkturner_at_[hidden]> wrote in message
news:000001c40145$ea9e7180$6300000a_at_onyx...

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

I did not find the documentation in your ZIP and can't really spend enough
time right away to read through the code. So I responded to your requirement
list rather than commented on the implementation. You do seem to gravitate
to hardcoding the window creation code in your examples though :(

> I've been thinking about that.  On the one hand, you Really Need a
> drawing-area widget,

No, not really - it is usually thought of as a "must have", but it really
isn't. Lots of form-based GUI applications are written in VB without issuing
any GDI calls, or at least any that are necessary to implement the
application functionality. HTML-based GUIs are an even better example; there
to have a drawing area capability you have to embed applets or ActiveX
controls.

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

Of course, there you will need a concept of drawing area widget that exports
a thinly wrapped graphics context. Even better, you can provide a way of
exporting a graphics context for all, or most widgets (though that might
prove harder to implement in a portable manner - sub/superclassing Windows
controls for the purpose of changing their look is an ugly endeavor).

If you're pressed for time (who isn't?), you can just provide the
graphics_context class encapsulating a platform-dependent handle/pointer.
Getting it from the widget (or widgets) is portable but from that point the
user is on his own. This should be sufficient for a surprisingly large class
of applications. Besides, there are portable 2D graphics libraries out there
already, even if not quite up to Boostish level of modernity. I have been
designing one 8-9 years ago and it looks like it's still for sale, but I'm
not gonna be plugging it here :-)

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

You'll still want to have those "metric" (or English :) ) dimensions - they
are very, very convenient when you create professional looking graphic
designs... provided you can reliably query the screen DPI. Perhaps a
3-tiered system of dimensions will be universal enough: NNN pt + NNN px +
NNN fil (borrowing a term from TeX). I like points better than inches or
millimeters, but that's just personal preference.

...Max...