[GUI] Re: Gtk and Object I/O

Nick Name nick.name@inwind.it
Fri, 24 Jan 2003 13:18:13 +0100


On Fri, 24 Jan 2003 03:26:35 -0800
John Meacham <john@repetae.net> wrote:

> 
>  that said, a low level display PDF/SVG esque layer would be a nice
>  thing to be standardized, but is orthoganol to the widget set GUI
>  concerns. you will find most of the work done for you in drawing
>  libraries built on top of OpenGL which are several.

BTW, some of the problems which have been exposed in this discussion,
for example heavyness of network transparency, and portability, could be
solved well by adopting a document model for the user interface, and
creating a server (xml would perform pretty good in this task) wich
renders the user interface and passes back user input to the
application. This is what the adobe DPS system did, and in some extent
what apple's quartz does right now.

An xml approach could enable nice features like attributed cut and
paste, and also cut and paste of user interfaces directly from an
application to a form designer. A well done document model could handle
animations, and direct connections between gui elements whose behavior
is so simple that it does not need to pass through the application.

The renderer could have an implementation as an Xwindow extension,
indeed.

So the network load would get lighter, and also the user interface could
be faster. I think apple took a good direction with quartz.

Is anyone on this list (which is rich of GUI-experienced people) aware
of projects wich have a good document model for a GUI, besides XUL wich
gave me the idea? Do anyone know good reasons why this model fails?

I guess that the too-much mentioned "portable backend" could be such a
document renderer, which we can implement in haskell to produce it
quickly; the main problem to my eyes is to find a standardized document
model.

Vincenzo