[cells-devel] Inheritance from model, not model-object?

[Kenny Tilton]

Mikko Ahonen wrote:
> On Wed, Jul 9, 2008 at 4:04 AM, Kenny Tilton <kennytilton at optonline.net 
> <mailto:kennytilton at optonline.net>> wrote:
> 
>     Go with model, the family class and lots of other good stuff assumes
>     that. You might be able to leverage some of that code.
> 
> 
> OK.
>  
> 
>     OK, that is the second explanation: with Cells we really have to
>     build an abstraction that hides the callbacks, so in my GUI work the
>     first three days are spent hiding the callbacks so I forget they are
>     there. :)
> 
> 
> I ended up writing some wrappers around CAPI already to simplify some 
> setf-ery, so this is not a biggie. This way setf-every was not too bad, 
> but when I extrapolated the work that needs to be done, the vision was 
> callback hell.

Yes. Brooks identified this as the big problem with software development 
in general: an exponential explosion of complexity as the number and 
kinds of data points grows in ever larger applications, because these 
data points tend to be interdependent. Any one change must be propagated 
reliably to all the right other data points, in the right order. That is 
not only hard, it is also not fun, nice to have that managed 
automatically just as modern languages manage memeory automatically.

>   
> 
>     If you look at Celtk or Cells-Gtk you'll see how I feed information
>     from callbacks into the cells web so I can forget they are there.
>     (Cello is just a wrapper for celtk.)
> 
> 
> I'll look into them more deeply.
>  
> 
>     Not an important feature <g>, just an amazing manifestation of the
>     power of the paradigm: a behavior like that /by accident/!
> 
> 
> Sounds very cool. So far the biggest mind-fuck with my limited 
> experience of cells is how it completely turns programming on its' head. 
> Almost everything turns into dataflow, ...

Yes, programming reverses direction. Instead of a programmer sitting 
there handling a state change figuring out how to push the change 
throughout the rest of the application, they just write standalone 
black-box rules and the Cells engine tkes any change and pulls the 
change thru the rest of the application.

And it is hard to do just a little dataflow, because once you start on 
this the cells is where the action is, so to see a change other things 
must be cells, too. The good news is that cells are more fun anyway, so 
it is OK that one gets forced into using cells everywhere. :)

which seems to at least
> temporarily increase the number of cells.

I won't have time to write it up, but I inadvertently stress-tested 
Cells. My app got a little sluggish on some things when I had about five 
thousand instances and over eighty thousand Cells. I fixed my bug and 
got it down to a couple thousand instances and (IIRC) twenty thousand 
Cells and things are quite zippy. They absolutely screamed when I 
activated OpenGL display lists a couple of places, but then i got into 
some imaging bugs and I really do not have time to mess with OpenGL 
right now.

Anyway, I was surprised and made a mental note to stop thinking about 
Cells as expensive. They may even be faster: i did another benchmark to 
see how much work was being done on each change to ensure the Cells 
integrity and it was much less than I thought. I knew cells guaranteed 
that only rules that needed to run would run and that that would make 
things optimal, but what I also saw was that the integrity rules did not 
force Cells to visit almost every cell to see if it should run, as I had 
feared.

So i would wait for performance to become a problem. If/when it does, 
you can probably uses synaptic Cells to minimize recomputation, or 
perhaps the application will suggest a new cells trick -- recent work on 
  a Cells-ODE had me implement user control over propagation so one 
could do a bunch of state changes and propagate just once. ie, where the 
user knows multiple state changes can safely be treated as one, they can 
now get that by wrapping them in with-user-propagation (or whatever I 
called it).



> 
> The thought process is interesting. For example, I denote the selection 
> of preview by flipping background and foreground colors. The parent 
> container knows the selected child. In setf-ery, the (setf selected) 
> method of the child would change the colors. First idea is to make each 
> child have selected cell watching the selected cell of parent.
> 
> Then define observer on the selected of the child to actually change the 
> colors. When I did that, I realized the need to ask for the colors from 
> the parent, and setf them to local variables. Next, I noticed that hey, 
> maybe foreground and background could be cells instead of local 
> variables, and watching for the selected cell of the child. I ended up 
> with one-line and 3 line observers for background and foreground, 
> instead of single 15-line observer for the selected.

Welcome to the club. Feels like a free lunch, eh? :)

> 
> Now the next thought is that perhaps I could get rid of some of the 
> intermediate cells, in this case the selected cell of the child. I guess 
> when you turn programming on its' head, the dataflow becomes the 
> "difficult part". My intuition says that at least to some point more 
> intermediate cells makes dataflow more visible and reusable. So I kept 
> the selected. But this may be because my background is in C shop where 
> code readability was emphasized.
>  
> 
>     btw, if you are going to stick with CAPI the way to go is replicate
>     the Celtk/Cells-Gtk/OpenAIR family of wrappers with sufficient glue
>     to more or less make CAPI disappear. I am pretty busy these days,
>     but I have an obscure interest in seeing that happen, and it is not
>     all that hard, I'd be happy to help.
> 
> 
>     Otoh, Cells-Gtk or Celtk free you from a Lispworks lock-in (not that
>     that is a bad thing).
> 
> 
> Great.
> 
> On this project I work with an user interface designer who is very 
> visually oriented. Tk is a non-starter because the controls do not have 
> a polished look. (Yeah, I know.). 

Do you know about the Tile package? I believe they are trying to be more 
native on the widgets. There is Tile support in Celtk, just not sure how 
robust it is -- I make all my own widgets using OpenGL.

Does your designer need "native", or do they just need "beautiful"? 
Perhaps they would get off on designing their own widgets.

> CAPI provides native GUI controls that 
> are barely sufficient. But CAPI already limits us, however. For example, 
> OS X Cocoa supports three sizes of controls, whereas CAPI has only one.
> 
> I also don't like vendor lock-ins. What I would prefer would be an 
> open-sourced version of something like CAPI, and cells-CAPI to go along 
> with it. I think splitting this into two different projects is better 
> than single one, because you can get those cells skeptics involved, too. 
> I think open source CAPI could be one of the biggest things missing from 
> Lisp right now.
> 
> The first step into that direction would be to develop open source 
> cells-CAPI.  Perhaps it would also get more people interested in cells. 

I think that will require OpenAIR, the web 2.0 incarnation of cells.

As for getting more people interested: Cells picks up one new user every 
year, and it looks like you are the one for 2008 -- I have six months 
before I have to worry about finding another user.

> I am ready to incrementally work towards something like this during this 
> project, but of course, my deadline is impossible (like always).

Talk to your designer, and check out my beach rants on Google video. 
What I am sensing is that widget sets are terribly constraining when it 
comes to building fluent GUI experiences for users. Does your designer 
also have an interest in the user experience, as well as the visual 
quality? In cello I have core classes like view and control and then i 
just make up an interactive screen element as i need it, with whatever 
rendering and event handling I have in mind. Instead of forcing my 
design into the pigeonholes determined by a fixed widget set, I just 
follow the application and the GUI elements follow me. :)

cheers, ken