From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-29 17:49:59
* David Abrahams <dave_at_[hidden]> [2004-12-29 16:37]:
> Alan Gutierrez wrote:
> > * David Abrahams <dave_at_[hidden]> [2004-12-29 13:52]:
> >> 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.
> > Materialization is a good strategy, but it doesn't address the
> > problem of rendering.
> Can't you image the native controls into an offscreen buffer and then
> apply whatever transformations, masking, etc., that the framework likes
> in order to display it in the right context?
Core point is that the library needs to make rendering
strategies generic. If so, materialization is strategy, and
there are others as well.
Also, what about events & accessibilty? If you render the
control off screen on a buffer, and take the result and paint it
onto the client surface, the lack of the native OS control,
well, I'm sure a Win32 GDI component is counting on a GDI HWND
for event notification.
So, render off screen, but then you have to figure out how to
send events to the hidden control?
It is an interesting hybrid approach, but I don't know that it
works for the rouge Win32 GDI.
-- Alan Gutierrez - alan_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk