[cells-devel] Interesting changes to Cells

[Ken Tilton]

No, it ain't Cells4.

One is a bug fix to ruled-then-input cells:  "ensure current" used to be
satisfied by a cell being flagged as input. Of course a ruled-then-input
will not be valid initially, so the test is now that something is c-validp
as well as inputp.

The more exciting change (no, i did not run the Cells regression test, but
my hairy application seems to work) is one I have seen coming for a while:

Supose have something like:

    (make-kid 'ct-button
         :enabled (c? (some #'non-empty (kids (fm-other :thing)))))

This button is part of a fixed application GUI and it keeps an eye on the
kids of :thing. Now thing happens to be a component inside a little
workspace, and other user controls allow them to switch the target being
worked on in the workspace. A change to the target pretty much rebuilds the
entire contents of the little workspace pane, including making a new widget
with the name :thing.

Well, this used to work without skulduggery because fm-other used to record
dependencies everywhere it went in searching for :thing. Maybe that is
something I should reinstate (I just realized). Anyway, the fix I came up
with today seems Deeply Sensible, so let's see how it pans out:

If :thing itself goes away (going back to the above example) at some point
c-quiesce will disconnect the kids cell as a dependency of the button
enabled cell. The fix is to flag any caller (dependent, such as enabled) as
":uncurrent", a new state between :unevaluated and :valid. I don't like
dirty words or variable names, cll notwithstanding. And dirty is vague where
uncurrent says what it means and means what it says.

What we are saying is that a dependency on cell X of instance Y implies a
dependency on the existence of Y. That just seems like a very safe thing to
say, so let's see if this works as well as a kazillion kids dependency that
would arise from a dependent modelspace search.

kt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20061017/ab4f5a6a/attachment.html>