More thoughts... Andy Chambers wrote:
I'm going to go back to celtk and try to understand the way it does things a bit better and see if there's anything fundamental I've missed. I should maybe code the apropos thing in celtk to check how the user code should look and make similar sort of code work for the web.
That's a good idea, btw. A bit of work but I guess all the widgets are there and it would be a good learning experience. But first send me a zip of your latest/greatest so I can stare at it in parallel.
Here's a quick question. If you want to make the kids of a mk-stack dependant on some other field in celtk, do you have to explicitly (make-instance 'stack :kids (c? ...) or should you still be able to use (mk-stack () ...)
As I said, that should work and a very quick glance at the example you sent last time looks reasonable, so send me what you have now and we can sort it out pretty quickly. One general pointer, to be remembered especially when nothing seems to be working: always call cells-reset at the start of any test. It's a long story, but there is a global *stop* that gets set when things go wrong that cells code checks before doing anything, as a way of getting the thing to actually stop in a situation where a process keeps feeding us events even after we have backtraced, putting us in a loop as we try to handle the new events and backtrace again. It happens pretty often that I roll some little test thing and get lazy and do not include the call to cells-reset, leading to some pretty serious head-scratching until I notice /nothing/ works and then remember cells-reset. kt