[General] Movement hook?

[Adam Spitz]

Dan,

I've been away from LK lately, but I'm starting to get back into it,
and I was wondering whether you've made any progress with the
downward-propagating transformations thing that you mentioned a year
ago. (See below.) The smarter ticking strategy helped, but it'd be
nice if I could just know when the line's endpoint has moved. :)


Adam



On Mon, Jun 16, 2008 at 3:22 PM, Dan Ingalls <Daniel.Ingalls at sun.com> wrote:
> Hi, Adam -
>
>>Is this the right forum to ask little fiddly questions about LK?
>
> Definitely it is.
>
>>I'm trying to use LK to build a little application that's basically a
>>bunch of boxes connected by lines. I want the two endpoints of each
>>line to stay attached to whichever box they're attached to (even if
>>those boxes move around). Right now I'm accomplishing this by checking
>>all the lines every N milliseconds to see whether the box at each end
>>has moved (and if it has then I update the vertices of the line
>>accordingly). That works OK, but it seems like an ugly solution, and
>>it's turning out to be a strain on the computer.
>
> Believe it or not, ticking scripts are the first thing to try, simply because it's so easy.
>
>>I was hoping that there'd be some method somewhere that gets called
>>every time a particular morph moves (whether that morph was itself
>>moved, or whether its owner or its owner's owner moved or whatever).
>>I've been looking through the source code and so far I haven't found a
>>method that looks like that (but it's very possible that I've missed
>>it). Methods like setBounds and translateBy seem almost like what I
>>need, except that (if I understand correctly) they only get called if
>>the morph itself is moved, not if its owner is moved. I could probably
>>hack something together that would sorta work, but I was hoping for
>>some advice from someone who's more familiar with LK.
>
> This is an interesting case (I encountered the same thing in my engine example) because the lines don't match the tree model of graphics very well. ?One of the nice things about transformations on every node is that you don't have to broadcast translation changes downward -- usually, but not in this case.
>
> We're actually working on that code right now -- mainly to get a decent layout model in place. ?We have a downward propagation for changes in extent, and you example indicates a need for a matching protocol for transformations as well.
>
> You might want to stick to your ticking approach a while longer, in which case you can probably improve performance/response by adding a strategy to the ticking rate: ?use faster ticking for lines that moved in the last interval, and slower ticking for those that didn't.
>
> Let us know what you're up to some time -- another purpose of this list.
>
> ? ? ? ?- Dan
>