Boost logo

Boost :

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2005-10-07 08:15:09


Andy Little wrote:
> "Stefan Seefeld" <seefeld_at_[hidden]> wrote
>
>
>>Thus, the challenge is to find a way that allows us to develop
>>new GUIs in the spirit of Fresco, as well as wrap well established
>>GUIs, and have both be accessible through the same API.
>
>
> A low-level platform-independent API is a primary requirement. Whether it is
> possible to move beyond the wxWidgets and GTK API's is another matter.
>
> I guess you'd agree that it would be difficult to realise anything like Fresco
> in a platform independent way? For instance I believe that a top level glyph in
> Fresco can have an arbitrary shape, whereas in Windows you are limited to a
> "Region" made of rectangles and ellipses. IOW in Fresco you have the luxury of
> owning the screen.

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.

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.

Now, those applications that do require access to lower level rendering APIs
then need access to a different 'kit'. (Fresco provided 'FigureKit', 'TextKit',
'LayoutKit', etc.)
With that, an actual GUI is a compound of various 'kits' (i.e. APIs in terms
of development, or libraries in terms of runtime environment) which may or may
not be available on a particular platform. Thus the degree to which an application
is portable depends on how many such kits it depends on.

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.

Regards,
                Stefan


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk