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

[Mikko Ahonen]

On Wed, Jul 9, 2008 at 4:04 AM, Kenny Tilton <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.


> 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, which seems to at least temporarily increase the number
of cells.

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.

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.). 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 am
ready to incrementally work towards something like this during this project,
but of course, my deadline is impossible (like always).

Best regards,

Mikko Ahonen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20080709/a45e8cbe/attachment.html>