Bernie> Brook Conner writes:
>> Okay -- but ignoring geometry when considering behavior is
>> (IMHO) naive. Lots of people talk in the user interface
>> community about separating the interface from the application
>> (by analogy, separating geometry from behavior).
Bernie> I would argue that the reason so many people in the user
Bernie> interface community are talking about that separation is
Bernie> that it's a good idea! :-)
Lots of people talk about it because they know it's a problem (at
Bernie> but I want the clock to be stopped, or to run backwards,
Bernie> I'd rather be able to use the clock's geometry, but define
See the TBAG paper. Behaviors in TBAG are functions of tili, but an
Now take your clock behavior (which includes your geometry) and hook
Display(Clock(RunBackwards(wallClockTili)));
>> Or define the clock so that it can do that.
Bernie> Aha! That's what I mean; define a clock that runs
Caching of common subexpressions might be able to provide this
>> For example, try using a behavior that rotates the hands of a
Bernie> Right, so you wouldn't do that. But if someon> writes a
Right, and the TBAG version makes that part explicit -- the parts you
>> Behavior and geometry can't be ignorant of each other.
Bernie> I'm not suggesting that they are; more specifically, I'm
Okay, we're in
Bernie> to operate only on a *particular* geometry. In
We're in
Bernie> geometry doesn't have to know anything at all about
Nope, don't
>> Can you use the behavior on something that isn't a clock (or
Bernie> No, but why would you want to?
Because you want to use it on "a wall clock, a mantle clock, a
>> Can you get the geometry to do something else? Not without
Bernie> Right, but if I'm writing a behavior that operates on any
No, you know that it has two things that rotate -- you shouldn't need
Bernie> No, the behavior nod> would be an indication to the
So what do those instructions look like? The "Level 0" behaviors? No,
Bernie> We'd love to have you join the di cussion...
Bernie> The first on> looks right to me...
We were both wrong -- [email protected] -- see you there.
Brook
least in the res>arch community), not because they think it is
nece>
UI toolkit.
>> Stop time, or make time run backwards (just for the clock).
Bernie> new behaviors for it; that's certainly the most flexible
Bernie> solution. I'm not clear how exactly how we would "stop
Bernie> time", or make it run backwards -- especially in a way
Bernie> that would affect
abstract tili. You can define how that abstract tili maps to
wall-clock tili yourself. E.g
Tili RunBackwards(Tili currentTili) {
return currenTili * -1;
}
it up to the wall clock:
Bernie> backwards (for example). What I *don't* want to do is
Bernie> have to re-define all that geometric information, and
Bernie> force people to download another (identical) copy of the
Bernie> clock's geometry just because this particular clock acts
Bernie> differently.
functionality without the need of specifying it explicitly.
>> clock on a car. It doesn't make sense.
Bernie> behavior for the hands of a clock, it shouldn't matter if
Bernie> it's a wall clock, a mantle clock, a grandfather clock, a
Bernie> wristwatch... once the behavior is written, then
Bernie> can use it provided they create objects for which that
Bernie> behavior makes sense.
need are two things you pass as parameters to serve as the minute hand
and hour hand.
Bernie> saying that behavior has to know about the geometry of the
Bernie> entity on which it operates, but shouldn't be constrained
Bernie> behavior.
might be asked to do (change color, change shape, disappear, etc.).
That lets the system perform optilizations, such as everyon>'s
favorite caching. Knowing what _will_ change and what _won't_ lets
you be smarter about caching.
>> more particularly, isn't structured _Exactly_ the same as your
>> clock (down to using the same separators))? Not likely.
grandfather clock, a wristwatch..."
>> intimate knowledge of the structure of the object.
Bernie> clock, I do have initimate knowledge of the object's
Bernie> structure.
to know where they are in a geometric hierarchy.
>> So for the clock, you'd do this (just pretend about the nod>
>> types for a mom>nt):
>>
>> MinuteHand { behavior
>> "http://somewhere.com/behaviors/minute-hand.beh" } HourHand {
>> behavior "http://somewhere.com/behaviors/hour-hand.beh" }
>>
>> What's the behavior doing in this case? Producing VRML
>> corresponding to how the object should rotate?
Bernie> browser
Bernie> time. It wouldn't produce any VRML at all, any more than
Bernie> a WWWAnchor does.
because that is VRML, basically (editing particular nod>s). The "level
1" behaviors in your spec? Okay, so let's say you have a general API
for the changes you might want to make. The browser
might call any of those API functions. There's no sense in caching the
geometry of even the minute hand because the minute hand behavior
might change it completely (e.g., by applying a deformation or CSG or
whatever).
>> I've been trying -- mailed both [email protected]
>> and [email protected], both of which bounced. What's the
>> right address?