Mikko Ahonen wrote:
On Wed, Jul 9, 2008 at 1:41 AM, Kenny Tilton <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
_______________________________________________
cells-devel site list
cells-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/cells-devel
