[cells-gtk-devel] Re: GUI programming in CL ..

[Peter Hildebrandt]

Hi Greg,

Ken already brought up the main points.  However, I'm looking at things  
 from a slightly different angle, so for me the solution is somewhat  
different.

On Thu, 03 Jan 2008 04:15:37 +0100, Ken Tilton <kennytilton at optonline.net>
wrote:
> Greg Bennett wrote:
>> Hullo and Happy New Year from Greg Bennett ..
>>  I have been following with interest the c.l.l thread on GUI  
>> programming and the discussion of cells-gtk.
>>  A group us at the University of Waterloo has a project centred around  
>> the analysis of data; since we are in the Statistics Department there  
>> is a bias in the direction.
>>  The work began on lisp machines (xerox) and then moved to Macs, and  
>> (almost) to unix using CLX for the graphics component. I did most of  
>> the porting to Windows under Allegro + Common Graphics which makes GUI  
>> development pretty straightforward, as such things go.

The question is, of course, how do you define "straightforward" ;-)

>>  We are considering moving the whole thing to Linux and a  
>> non-commercial lisp - cmucl is a candidate. As we plan to do that, it  
>> makes sense to think hard about the graphics end for the project is  
>> highly graphical with lots of 2-D, 3-D dynamic plots which are often  
>> linked so that playing in one produces updates to others. We had been  
>> thinking of OpenGL for access to which which Cello sounds like a  
>> possibility. However, I am interested to note that there is no mention  
>> of OpenGL in the thread.
>
> Hey, Greg.
>
> I think "no opengl" just traces back to the original thread RFP, if you  
> will. Me, I am all OpenGL all the time. My 3d buttons are actually 3D. :)

I use opengl in my project, too.  There's a little world simulator, which  
I implemented using a little clos glue code between cl-opengl for the  
drawing and cl-ode as a physics backend.  I use glut (cl-glut is included  
in cl-opengl) for the drawing, giving me a simple window with nothing but  
an opengl canvas in it.  The main GUI has its own GTK window.

>>  Perhaps it is a poor choice, perhaps nobody has used it extensively,  
>> perhaps I don't understand what toolkits the wrappers in cells-gtk give  
>> access to.
>>  For us, porting to a new OS means rewriting the basic windowing layer  
>> including windows, scrolling, menus, dialogs, etc. so we are trying to  
>> get as much background information as we can before starting. Trying  
>> out  one only to find it is a poor choice doesn't seem like fun.

There's a couple different questions in here.  I'll try to sort it out:

- MATURITY - cells-gtk/celtk appear to be somewhat "cutting edge" compared  
to more established things such as clg or LTK.  That is, you get all the  
benefits (declarative programming, cells inside, etc), but -- at least  
with cells-gtk -- be warned:  you'll have to work on the toolkit sooner or  
later.  You cannot expect everything to work out of the box, because the  
odds are in your application you'll come to a point where you need some  
functionality that has not yet been integrated. AFAICT the develoment of  
cells-gtk/celtk are largely driven by demand, that is, the maintainers  
implement more or less what /they/ need.  clg for instance appears to be  
/a lot/ more complete than cells-gtk.  Then OTOH cells makes your code so  
much nicer.  It's a trade-off.

- OPENGL - Do you wish to use opengl and widgets /in the same window/?  if  
yes, celtk/togl is the way to go, as there is currently no opengl canvas  
in cells-gtk.  However, prompted by your question I did some research and  
found GtkGLArea [1] and GtkGLExt [2]. Later tonight I will look into  
adding one those to cells-gtk (can't tell which one to use yet.  GtkGLExt  
seems to be not actively maintained, and GtkGLArea provides hardly any  
docs.  There are deb packages for both of them).

[1] http://linux.maruhn.com/sec/gtkglarea.html
[2] http://www.k-3d.org/gtkglext/Main_Page

- CAIRO - There is experimental cairo support in cells-gtk.  If you just  
want to use cairo funcs to draw on some widget, there's support for that  
in the latest cl-cairo2 (Tamas committed my patch about two weeks ago).  A  
full blown drawing area, in which each primitive is represented by a cells  
model, is clickable, draggable, has a mouse-over-p etc. is still under  
development.  I've been using it in my application for about six months  
now, and I am in the process of clearing up the interface before I will  
release a patch.  Ken, is there cairo in celtk?

OpenGL vs Cairo is another question to ask. Cairo is arguably preferrable  
for 2D stuff (including a pretty postscript export), but does not support  
3D.  You might end up using both (like me).

- NATIVE LOOK - GTK is native on the gnome desktop, that is, your  
application will integrate perfectly with the rest of the system.  There  
is GTK for windows, but I don't know what the status of that project is.   
GTK for mac is still under development.  Tcl/Tk is available on all three  
platforms and looks native on windows and mac, but used to feature a  
"mid-80s look and feel" on linux (hard-edged, no font antialiasing, not  
theme-aware) .  Tcl/Tk 8.5 remedies the former two, but still does not use  
gnome themes.  Moreover, 8.5 is brand new, you'll have to depend on your  
users running Ubuntu 8.04, debian unstable, or else installing backports.   
If you plan on deploying your application no sooner than a year from now,  
this might be an non-issue (OTOH, my lab at Berkeley was running an  
ancient Red Hat Enterprise 3, which did not even support cairo)

- VERSATILITY - You might want to consider the range of available widgets,  
depending on what your application needs (a rich text editor, a list  
view/tree view, ...).  GTK seems to be quite complete, but I'm the wrong  
person to ask because I don't know Tcl/Tk well enough. Note that this is  
different from the completeness of the wrapper -- if some widget is  
available in GTK but missing in cells-gtk, it is usually quite easy to add  
support (add a few ffi bindings, define the new widget model, add some  
property handlers).  The same is probably true for celtk.  But if a  
feature is missing in the toolkit, you'll have to use cairo or opengl to  
roll your own.  This might be more hairy.  OTOH, Ken seems not to mind too  
much :) .

>>  I've written off-list because I don't want to drag OpenGL into a  
>> discussion which seems to be going along a different track; if this is  
>> poor etiquette, then apologies for the error.
>>  If you have any advice or (not xor) opinions you'd care to share eg.  
>> about possible choices of lisp or about OpenGL, I'd be a most grateful  
>> recipient.
>
> This is a no-brainer, you want Celtk with the TOGL (Tk OpenGL) widget. I  
> set it up a while ago so my recall is fuzzy, but I am pretty sure  
> somewhere out there is what I called Celtk3D, which is just Celtk +  
> TOGL, leaving straight Celtk as the project for those who did not want  
> the 3D bit. Me, I use Cello which is basically Tk with /just/ the Togl  
> widget, then everything done ground-up in OpenGL. You might be happier  
> with the full set of Tk widgets and 3D in just the subframes where you  
> need it. And then you are Lisp and OS independent, pick and choose as  
> you like.

Again, your choice depends on what you really want.  cells-gtk gives you a  
native UI (and the sample app test-gtk makes it easy to get started with  
all of 'em and test their capabilities).  Cairo is there and suitable for  
2D visualization.  If you need opengl, however, celtk is your choice (as  
of now).

It looks like SBCL is pretty popular, so you might want to check it out,  
too.

> btw, I note you mentioned "playing in one" in re the plots. If you want  
> to do more than display OpenGL, ie, use picking logic to make Ogl  
> "objects" into manipulables, it is possible Cello is what you want. But  
> I have not reinvented all that many widgets in Cello, just what I need,  
> so you might have some work there. Then again, the core Control and view  
> widgets in Cello make widget reinvention a snap.

This, again, is a matter of taste, I suppose.  Reinventing widgets with  
cello might be easy, however using existing widgets with cells-gtk is even  
easier.  OTOH using cello you end up with pure lisp and have full control  
over the internals.  Then, again, cells-gtk provides a standard native  
look and feel on linux  (including your application always using the  
current gtk api, thus looking native even in the future or with a custom  
theme).

Good luck and let us know if you have further questions.  I cc'd the  
cells-gtk-devel list, which might be another good place to get further  
information.

Peter


> kt
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/