From eBay at common-lisp.net Sat Oct 14 11:18:22 2006 From: eBay at common-lisp.net (eBay at common-lisp.net) Date: Sat, 14 Oct 2006 06:18:22 -0500 Subject: [cells-devel] New Unpaid Item Message from tany70 : #294653688662 Message-ID: An HTML attachment was scrubbed... URL: From kentilton at gmail.com Tue Oct 17 22:01:12 2006 From: kentilton at gmail.com (Ken Tilton) Date: Tue, 17 Oct 2006 18:01:12 -0400 Subject: [cells-devel] Interesting changes to Cells Message-ID: 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: From kentilton at gmail.com Wed Oct 18 14:04:35 2006 From: kentilton at gmail.com (Ken Tilton) Date: Wed, 18 Oct 2006 10:04:35 -0400 Subject: [cells-devel] Anyone remember how we fixed keystrokes not getting picked up in Tk text fields? Message-ID: Not sure if the problem got served here -- just checked the archives and do not see anything -- but in the past year I went back and forth with someone for a few days before we finally got text fields in the ltktest-ci demo to reliably notice keystrokes. I notice that ltktest-ci does not now reliably capture keystrokes. Possibly because the fix was an adjustment to the *event-loop-delay* (var name?). I actually do not remember the fix either. Can anyone remind me? Thx, kt -------------- next part -------------- An HTML attachment was scrubbed... URL: From frgo at mac.com Wed Oct 18 20:34:14 2006 From: frgo at mac.com (Frank Goenninger) Date: Wed, 18 Oct 2006 22:34:14 +0200 Subject: [cells-devel] Anyone remember how we fixed keystrokes not getting picked up in Tk text fields? In-Reply-To: References: Message-ID: Hi! I seem to remember that it was playing with the delay value (see ltktest-ci.lisp file) - choosing a value to low or too high resulted in keystrokes getting "lost". Frank Am 18.10.2006 um 16:04 schrieb Ken Tilton: > Not sure if the problem got served here -- just checked the > archives and do not see anything -- but in the past year I went > back and forth with someone for a few days before we finally got > text fields in the ltktest-ci demo to reliably notice keystrokes. > > I notice that ltktest-ci does not now reliably capture keystrokes. > Possibly because the fix was an adjustment to the *event-loop- > delay* (var name?). I actually do not remember the fix either. > > Can anyone remind me? Thx, kt > _______________________________________________ > cells-devel site list > cells-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-devel