* Andy Little <andy@servocomm.freeserve.co.uk> [2004-12-30 03:59]:
"David Abrahams" <dave@boost-consulting.com> wrote
Reece Dunn wrote:
With Carbon, I think you just use native controls.
With Win32 GDI you roll your own controls.
I think that this is not the right approach. You should only roll your own controls when that control isn't supported by the target OS. The Win32 GDI and Win32 controls/common controls are different things.
Not different enough, IIUC. They're both subject to the same (shared) constraint on maximum number of window handles. To make a windows GUI framework scalable it must provide for that. Not every widget on the screen can afford to be an OS control or window, even when there are appropriate built-ins (consider a grid of spreadsheet cells). One approach might be to make them "ephemeral," i.e. conjure up the actual OS thingy only when you need to draw or process clicks there and then throw it away immediately or soon.
This implies to me that graphics_element is the common abstraction, which might be one base class of a window
What about when you are not using graphic elements? When you are relying on resource files, you won't need a Boost graphics absraction at all. I don't think graphic_element is a base class, I think it is an implementation. I don't think you can have a grid without one, but you can have forms with out one. -- Alan Gutierrez - alan@engrm.com