[sugar] Re: Zoomable tracking protocol for non-windowed Cairo based objects.

[Don Hopkins]

The ScriptX tracking service was based on The NeWS Toolkit 2.0's 
tracking service (written in PostScript), which I adapted for ScriptX.
Credit for the design goes to Don Woods, Owen Densmore, Brian Raymor, 
and other people on the NeWS team, whose goal was to redesign the old 
NeWS tracking service and toolkit to be smaller and faster.

TNT 2.0 tried to minimize the number of objects, inter-object sends, 
event manager threads, coordinate transformations, share event interests 
(patterns to receive events), and centralize event processing in the 
global event manager.

It also had "safe" input handling, because NeWS threads (like the global 
event manager) could use synchronous event handlers (when appropriate, 
but not always), which were guaranteed to block the input queue and run 
the event handler before any more events were delivered. Synchronous 
event handlers enabled the window manager to perfectly track and 
synchronize mouse clicks, input focus and key distribution changes, 
without losing any events that slip between the cracks from changes in 
the window hierarchy, event handler registrations, and delays due to 
paging and network response. Safe input handling is especially important 
for slow networked computers (like a diskless Sun 3/50 or an OLPC) that 
need to respond quickly and reliably to user input!

I'm not sure how any of that synchronous event handling stuff would 
apply to the OLPC interface at the X11/window manager/GTK level. But it 
might be helpful for implementing safe input handling within a 
multi-threaded Python/GTK/Cairo application (like if you were making 
your own zooming Cairo based window manager in Python, which sounds like 
great fun!).

The "trackStart" handshake pattern and factoring of tracking classes 
should work well with Python/GTK/Cairo, since NeWS, ScriptX and Python 
all support multiple inheritance.

One subtle details that is worth mentioning: check out the way the 
TrackerMulti has the fallback trackStartMulti method that gets called if 
all of its children refuse tracking, so it can implement its own 
background tracking (like dragging a rectangle out to select its children).
The abstract TrackerMulti class gets mixed into any concrete tracker 
subclass that contains multiple child trackers.
A concrete TrackerGroupPresenter could contain multiple children and 
display them all at once, so would need to mix in TrackerMulti, but a 
tabbed pane with multiple page children would only want to display once 
page at once, so it would not mix in TrackerMulti -- instead it would 
just delegate tracking to the currently selected pane.

The documentation says some stuff about that, but doesn't really tie it 
all together, so I'm glad to answer any questions you have.
The ScriptX code has comments, and the syntax is a lot like dylan or 
lisp-like languages with a kind of algol- or python-like syntax.
Method definitions have "self {class <class_name>}" constraints that 
declare the class of the self parameter, to make it a method of that 
class. And of course "arg ... -> <expression>" is a lambda expression. 
The syntax to send a message to an object is "<generic_method_name> 
<object_expression> <arg> ...", and it has @quoted atoms, keyword: and 
#rest parameters, just like Lisp.

http://www.art.net/~hopkins/Don/lang/scriptx/tracking.html
http://www.art.net/~hopkins/Don/lang/scriptx/tracking.sx

    -Don


Antoine van Gelder wrote:
> Don Hopkins wrote:
>> On the topic of tracking with non-windowed cairo objects, and 
>> zoomable interfaces:
>>
>> Here is a design document describing the ScriptX Tracking Service 
>> that I developed at Kaielda, to solve some of these problems inherent 
>> with efficiently delivering events to graphical (non-windowed) 
>> objects, through a series of transformations (and offscreen buffers).
>
>
> This looks pretty cool - thanks Don!
>
> I've implemented a lot of this functionality but to put it bluntly 
> it's been crying out for a refactor - I particularly like the way 
> you're decoupling the event coord transforms - this is something that 
> has been causing me particular pain as I've tried to scale up my 
> object model.
>
>  :-D
>
>  - antoine
>