[cells-devel] Re: [cells-gtk-devel] Re: Hacking the gtk-ffi

[Ken Tilton]

Andy Chambers wrote:
> On 10/29/07, Ken Tilton <kennytilton at optonline.net> wrote:
> 
>>Andy Chambers wrote:
>>
>>>On 10/29/07, Andy Chambers <achambers.home at googlemail.com> wrote:
> 
> 
>>>OK.  I think I know why its not working.  The ffi call never gets made
>>>because cells only uses it if either the new or old value is not nil.
>>
>>Properties are propagated from the Lisp model to Gtk by "observers" on a
>>slot. Celtk and Cells-Gtk generate these observers as part of the
>>macroexpansion of the def<i forget> macro to which it seems you
>>correctly added the slot. It should not matter that the value (as you
>>imply) never changes, because Cells understands that an initial
>>propagation is necessary so observers and observed start out in synch.
>>
>>You can check that you see an observer in the macroexpansion, then that
>>that is being called. If not, I would have a concern that Cells-Gtk has
>>not been upgraded to use the latest version of Cells, because I have a
>>faint recollection that possibly older versions do not propagate a nil
>>initial value. I would be shocked if it did not propagate a non-nil
>>value, so one thing you might try as a sanity check is to specify a
>>non-nil just to see if anything fires.
> 
> 
> The observer is being created in the macro-expansion.  That's how I knew to
> add the ffi definition (how cool is it that the software knew what function it
> needed to call before I did :-)).
> 
> My immediate problem is fixed by overriding the generated observer to always
> propagate the value so I think you're spot on about cells-gtk not
> using the latest cells but I'm starting to have some fun now and feel
> a lot more confident about trying to upgrade.

You mean upgrade Cells-Gtk to the latest Cells? Interestingly, one of 
the things I did in later versions was first to handle propagation by 
posting tasks to a fifo queue (so we do not go recursively deeper on 
propagation, which can make debugging harder) and then to allow 
specification of a user handler for processing the queue. I did the 
latter because Tk (not Gtk) can be a little sensitive to the order in 
which things happen and a user queue handler allows me to tag all 
messages to Tk with some keyword or other which then gets used by the 
queue handler to order tasks to kep Tk happy. I do not know if Cells-Gtk 
has the same issues, or if they reach the application user of Cells-Gtk 
itself, but there it is. The latest Cells also put the whole thing on a 
much solider foundation correctness-wise, at the expense of a little 
loss in transparency. The "correctness gap" was interesting in how few 
problems it caused, but I always knew the gap was there and when I 
undertook RoboCup that application definitely broke for those reasons, 
so Cells got fixed.

I think you cannot "upgrade" Cells-Gtk, I think you have to make a giant 
leap for guikind and call it Cells-Gtk3 (or 4, I actually forget if I am 
at Cells3 or 4, the good thing being I do not think about Cells anymore 
(tho every 4-8 months I run into a solid bug (another reason to, um, 
upgrade))). Cells-Gtk3 will be an interestingly big job since I /think/ 
you will be getting into a user-queue handler that knows about Gtk, but 
as did Cells-Gtk Classic you can start by mimicking Celtk.

kt