Re: [boost] GUI coordinate units (Was: GUI foundations)

From: Manfred Doudar (manfred.doudar_at_[hidden])
Date: 2005-10-09 21:40:55

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