[cells-gtk-devel] Cool

[ktilton at nyc.rr.com]

----- Original Message -----
From: Peter Denno <peter.denno at nist.gov>
Date: Friday, February 11, 2005 10:14 am
Subject: Re: [cells-gtk-devel] Cool

> On Friday 11 February 2005 18:24, Peter McDermott wrote:
> > I managed to get the cells-gtk demos to run earlier today on clisp.
> > Very cool!
> >
> > If, in the next few days, I'm able to transform the gtk-demo 
> code into
> > the beginnings of the lisp/gtk application I working on, I will 
> be very,
> > very happy.
> 
> I did the same over the last week or so. It wasn't too hard.
> 
> > I read the documentation on cells itself and briefly checked out 
> the gtk
> > example code.  One thing that isn't quite clear to me, is, why 
> does UI
> > programming lend itself to a system like cells?  I mean, I 
> understand> the spreadsheet analogy for a spreadsheet, but not 
> necessarily for a UI.
> 
> Well, having not written cello or cells-gtk, but now used it, I 
> guess I am 
> somewhat a neutral observer: GUI programming can get very messy 
> very fast. It 
> appears to me that the cells approach really does manage the 
> complexity of 
> the code nicely.

Yes and yes. As GUIs get more interesting, they get more and more user controls, and more and more visible things which must stay consistent with the changing state of those controls. How often do we hide/uncover a window or resize it when the display gets all messed up, just to get the code to redraw from scratch and get past some update bug?

With Cells, a control does not need to go change, say, the justification of a text widget. The control just changes it's own internal bound value from :left (or 'left) to :center to :right. The text widget is coded to watch the changing state of the justification control. This kind of thing decouples widgets and makes widget self-documenting: if you want to know how the text widget gets justified differently, look at the rules (...well, maybe the rendering method) for the text widget.

One can look at this way: Cells support a declarative style of development. I just think about all the things that can effect the state of one slot and I write a rule to cover those things exactly as I want. Then the Cells engine makes it all work. And, again, one gets nice documentation of that slot.

When all sorts of different code in different places is dumping values into any given slot, well, you can see a buggy value in a slot and not be sure where to look to find out how it got there. In the declarative model, there is never any doubt, just one rule to stare at.


> And WRT to the implementation of a GTK binding 
> for lisp, and 
> what I can see studying Vasilis's code, it seems it made the 
> implementation 
> more elegant too.

Cool. Vasilis did an amazing job, with no input from me at all. Zero. I am still in shock. I have not cast a critical eye on his use of Cells, so I am not sure it is as declarative as it could be. I see a lot of SETFs in c-output functions, and wonder if the place SETF'ed could not have had a rule simply sampling the cell with the c-output. But I also think Vasilis may be a better programmer than me, so I should keep my mouth shut until I find an actual case of that. <g>

> 
> > Any pointers on how to wrap my traditional message-loop-dispatch 
> thought> processes around cells-gtk would be much appreciated.

If you at least download the Cello code, you will see how I tend to glue the declarative model of cells with the event/message-loop model of typical gui programming. In brief, any event/message such as keydown is handled by creating a cell proxy for the event. ie, I give the Window class a cell slot for "keyDown" (or "keyState" to do a little early processing of keyDown/keyUp and collapse it into one). Then in the message/event handler you just see:

     (case (message-type this-os-event)
       ...
       (WM_KEYDOWN (setf (keystate this-window) 'down))
       ...)

If I am using a window manager that just gives me event/messages, you might just see:

(defun registered-event-handler (window event)
     (setf (event window) event))

Then diff cells on the window look to see if they care about the event. After that, it is all a cascade of Cells firing and calling their output functions.


> >
> > Also, is there any relationship between cells-gtk can cello?
> 
> Cello is the "cells" in "cells-gtk"  You loaded cello to get 
> things running.

I named Cells and Cello too closely. :)

Cello uses Cells. Cells-gtk uses Cells (not Cello). Celtik uses Cells (and Ltk). Otherwise, those three have nothing in common.

> 
> > By the way, I'm new to lisp--just started six days ago after much
> > reading about it.  So that may explain some of my thickness.

Well, don't feel bad if Cells gives you fits at first. Even veteran Lispniks sometimes get frustrated by the lack of documentation. And it seems like magic until you get used to it. And it is a paradigm shift. I invented it (ignorant of all the prior art) but I still found myself falling into an imperative style from time to time for a good 6-9 months.

kenny