freenode/#clim - IRC Chatlog
Search
14:21:35
jackdaniel
currently when we dispatch event, we dispatch it to an event queue associated with the target sheet, which is initialized to be the same as the frame
14:22:29
jackdaniel
then when we read a gesture, input-wait-test and input-wait-handler check, if a gesture selects an object which the input context (i.e we wait for a presentation of type integer) and if it does, then it performs a non-local exit
14:23:36
jackdaniel
each frame (usually) runs in a separate thread and has a separate event-queue, and their stream-read-gesture is run in a different typed input context, so we can't know what presentation type other frames "wait for"
14:24:14
jackdaniel
so the typed input context in which the event is considered depends on the queue in which it is dispatched
14:25:18
jackdaniel
in one frame we wait for integer (which is focused), then we click on a presentation displayed on a sheet in a different frame. if the event is queued "to us" we may use the presentation.
14:29:05
jackdaniel
method dispatch-event checks, what is the port's focused-sheet and takes the event-queue from it
14:32:47
jackdaniel
n.b same applies to a tracking-pointer, we can't track it across different frames if they do not share the same event-queue
15:03:46
slyrus
jackdaniel: regarding the zooming via interaction with output-record, I would think we should support (and test) both approaches.
15:04:31
jackdaniel
slyrus: I can only work on so many things at the same time :) regardless, I think that this proof of concept is at least interesting
15:06:56
jackdaniel
it won't work for text output records, but that's a bug in the implementation of medium-draw-text (at least I think it is without taking a deeper look) -- there is no around method for transform-coordinates-mixin
15:07:36
jackdaniel
instead text otuput records inherit from gs-transformation-mixin, what works quite differently, however is meant for the same thing as pre-transforming coordinates when outputting output records