How the Slate works

In a nutshell, the Slate messes about with canvas item tags in order to give the illusion of hierarchically-grouped items, and without the cost of implementing a truly recursive implementation. Although the idea is simple enough, the implementation -- especially when it comes to dealing with bindings (which still don't quite work properly) and maintaining full backwards compatibility with the Tk canvas -- is not. This section tries to give some understanding of the basic Slate mechanisms.

Each complex item is assigned a unique ID by the Slate when it is created. The ID starts with an underscore to distinguish it from Tk canvas IDs (which are integers).

Slate rule 1: Every simple item contained in a complex item is tagged with the complex item's ID.

Complex items can in general contain other complex items. Thus, the extension of the above rule is that every simple item is tagged with the IDs of _all_ complex items in the hierarchy above it. Unfortunately, the canvas does not maintain item tags in any particular order, so we are forced to add an additional tag to each simple item to identify the immediate parent. This tag is the parent's ID prefixed with a "!".

Slate rule 2: Every simple item contained in a complex item is tagged with the ID of its immediate parent prefixed by "!".

That is really all there is to it. To move a complex item, all we need to do is ask the canvas to move all items tagged with the complex item's ID -- a single call to the canvas. More complex operations -- finding items overlapping a given region, or binding scripts to items, for example -- get much hairier. Partly this is because of the extra work that has to be done testing and changing tags, and partly because of the semantic issues that arise when considering what these operations mean on complex items.

(As an example of the latter, suppose that A contains B, and noth have a script bound to them. If I click on B, B's script should obviously get executed. But what about A's script? Should I execute that too? At first, the answer seems like yes: do whatever both items have asked for. But suppose the scripts move the items a certain amount: B will get moved twice! So then A has to somehow know that B will be moved and account for it -- but then we have to guarantee something about the order in which the scripts are executed. And so on...)

This section will be expanded in future.

Back up
Tycho Home Page


Copyright © 1996, The Regents of the University of California. All rights reserved.
Last updated: 96/12/11, comments to: johnr@eecs.berkeley.edu