Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: [Caml-list] Re: Tcl/Tk and RH 9
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jason Gibson <jason@i...>
Subject: Re: [Caml-list] Re: Tcl/Tk and RH 9
 >What about looking at Cairo (Ex Xr/Xc) and either bind to that, or
 >reimplement their protocol in ocaml. Cairo is early enough in its design
 >that it can still be influenced enough if someone looks at it, and
 >points them problems related to doing ocaml bindings.
 >Basically it is a vector rendering framework, linked to SVG graphics,
 >and which should enable to have a vector rendering model (on top of the
 >X RENDER extension i think), but which can target various graphic
 >systems, including X, local image buffers and Postscript and PDF as
 >planned output support. I don't know about windows support, but MacOSX
 >support should not be all that difficult to add, and since they also
 >have an OpenGL rendering path, it should run on every OpenGL supported
 >Sven Luther

I'm glad to see that I wasn't the only one who thought that xr\cairo\svg 
would make a
good base for windowing toolkits.  I was thinking that having the low level 
vector based would allow you to do lots of interesting things.  For 
example, you could
do what xml has done, ie allow people to separate out the different classes 
of data easily.
Like how html has presentation\data all bunched together, our vector gui 
could have the
layout\data\communications\etc all separated out, allowing for better 
functionality on
each level. One of the layers of xml-style data could be a communication 
path, allowing your
program to be less dependant on the gui model (like an event loop).  It 
would also let you
expose your gui program to other programs, available for use in a scripted 

One could build a gui application like one draws a picture.  Each shape 
could be made
separate, so doing things like floating toolbars would be trivial.  You 
just move that particular
shape, and all its children to a new location.  You could group 
programs  together easier by
joining shapes and doing transformations on them.  Maybe you could build 
gui components
as little programs that you connect together, like how you use pipes to 
link a chain of programs.


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: