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
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
