Mikko Ahonen wrote:
On Wed, Jul 9, 2008 at 1:41 AM, Kenny Tilton <kennytilton@optonline.net mailto:kennytilton@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