"David Turner" <dkturner@telkomsa.net> wrote in message news:000001c40145$ea9e7180$6300000a@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...