Stefan Seefeld wrote:
The original Fresco project was a research efford that clearly aimed for a new display server architecture. However, the released packages provided a toolkit to construct GUIs within existing GUI environments, simply by allocating top-level windows from the 'system' and then doing all the rendering inside (i.e. widgets and other graphics) by itself. So yes, technically it would be possible. We then moved forward by putting the actual display server into its own server process, potentially distributing the 'scene graph' across processes (using CORBA). The idea was to provide an API that abstracted away the details, such that the user didn't need to be aware whether it helt an actual widget or just a proxy.
Which IMO is the right thing to do.
While the particular choice of CORBA (and location-transparency) were probably unfortunate (at least at such a fine-grained level) I believe that the key to a flexible GUI API is still the same: provide abstract factories that construct a GUI and return high-level handles to it. That can be raw widget pointers, proxy objects, or what not. For example, a 'button' is simply an object that you can click on, and which emits a 'clicked message'. At this level it doesn't provide access to rendering routines or anything else that lets you fine-tune the button's look & feel. Doing this provides sufficient flexibility to the factory to either choose a native toolkit backend, or let Joel reimplement it on top of antigrain.
Yay! for Antigrain - but seriously ... the underlying mechanics of it all should be hidden, and I think we all agree that the holistic goal here is to sort out an API that would suit all, and remain sufficiently extensible. I concur here with you that abstract factories are just the way to go ... but how many here need convincing of that? I would only say that care should be taken to not make such a project too top-heavy (re: ambitious design), which is what I think Fresco in part suffered from; but I think the Fresco experience has much therein which can be drawn upon, not to mention the success/failures of other GUIs since. (Secretly), I'd like to see some kind of Fresco re-birth through a Boost-GUI, but then maybe I'm still dreaming.
Again, the central point is to find clever key abstractions that all such kits (at present and in the future) can agree on, to provide sufficient flexibility for developers to implement it and let it evolve.
You have my vote, anyone else ? Boosteres, it'd be nice to move on to something tangible, wouldn't it ... ? Cheers, -- Manfred MetOcean Engineers www.metoceanengineers.com