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

[Kenny Tilton]

Mikko Ahonen wrote:
> On Wed, Jul 9, 2008 at 1:41 AM, Kenny Tilton <kennytilton at optonline.net 
> <mailto:kennytilton at optonline.net>> wrote:
> 
> Thanks for the quick reply,
> 
>     If you saw something in model absolutely necessary for Cells to
>     work, I goofed. :)
> 
> 
> My question was based on error message that indicated that model-object 
> was not exported (or something) when I was trying to inherit from 
> model-object.

Oh, I am forever having to export things that should have been exported 
in the first place except I never actually do that (go through a 
library, think about what should and should not be exported, then do 
so). So, yeah, model-object should be exported.

In case it was not clear, please do not take any failure to export as a 
/definite/ sign that you have gone wrong. Mind you, Cells has been used 
so heavily and is so small that normally anything that should be 
exported is exported, but this design bit is where I thought "well, 
someone might want to do this differently, let's not lock anything in" 
and we just have not yet run into that someone. )


> 
> I looked into doc/*.lisp, test-cells/* and also cello, and only found 
> references to model, not model-object. I figured that perhaps 
> model-object was some left-over from previous versions, or something.

I understand. No, as I said "model" is my preferred way of managing an 
object-space if you will, and that is all my code (and some of Frank's) 
so it just looks as if model rules the Cells world.

> 
> This is what I got:
> 
> "Error during finalization of class #<STANDARD-CLASS X 2173E1B3>: Cannot 
> compute the class precedence list of #<STANDARD-CLASS X 2173E1B3> 
> because the following class is not finalized #<FORWARD-REFERENCED-CLASS 
> MODEL-OBJECT 223FBB43>"
> 
> (this is LispWorks 5.1 on OS X if it makes any difference, and extending 
> a GUI component)
> 
> Works fine with model, though.

Go with model, the family class and lots of other good stuff assumes 
that. You might be able to leverage some of that code.

> 
>     Cool. Philip Eby also talks about callback madness as motivating his
>     Cells clone, Trellis (a Python project). I never thought about it as
>     a callback thing, but it seems to be a recurring theme. :)
> 
> 
> Not that I would know much about GUIs, but perhaps it depends on the 
> model used in the GUI library. I am now experimenting with LispWorks CAPI.

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. :)

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.)

> 
> For example this screen become a hassle immediately with callbacks, even 
> if it is quite simple in principle:
> 
> User is editing two-level hierarchical data. Thus, parent objects have 
> children. This view shows single parent. The form on the right is used 
> to edit a single child. On the left I have preview of each child for 
> this parent. The child previews are clicAkable, and select the object for 
> editing. When I edit the data, the underlying model should obviously 
> change. So should the preview, if corresponding fields change, as well 
> as the title and some other parts of the view as well.

ISTR Peter H. tackling something similar with Cells-GTk and having to 
extend the GTk wrapper to be more aware of such things.

You remind me of a recent mindfuck: I have this math application that 
has a cool wysiwyg math editor. Kids can be working on multi-problem 
assignments, but I show them only one at a time. A grid of little blank 
rectangles signifies the collection, and they click on any to call up 
that problem for work. I had already done textual tooltips, and it 
occurred to me that my gui was so cool I could just as easily make a 
hairy math expression into a tooltip. Now I knew they might need time to 
think so these tooltips do not go away after a few seconds as per 
standard. And a tooltip sure does not capture the edit focus. Omigod. 
Without writing a line of code I tried it: yep. If I moved the mouse 
over the icon for a problem and got the tooltip, I could then continue 
editing the problem and see both the problem and its tooltip change at 
the same time!

Not an important feature <g>, just an amazing manifestation of the power 
of the paradigm: a behavior like that /by accident/!

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).

kt