Steven D. Majewski <sdm7g@virginia.edu> wrote:
> 
> I reread the section in chapter 9 of Lisp-Stat on linking plots,
> and gave it another try. What I've been trying to do is to link
> points in one plot with other objects. Initially and specifically,
> I was trying to link name-list points with overlays on a scatterplot.
> After several failed attempts, I thought I could do it more generally
> and debug the problems easier as well, by writing a generic adapter
> class that translated between :POINT-STATE, :LAST-POINT-STATE, and
> :ADJUST-SCREEN-POINT messages to/from :STATE, :LAST-STATE & :ADJUST-
> SCREEN messages to the nth object on the adapters internal list. 
> 
> This also ran into problems: other methods, not implemented in my
> adapter, and not documented as part of the linking protocol seemed
> to be getting called, and some other things didn't work as I expected.
> The many-to-one adapter was still too complicated to be a trivially
> obvious example, so I tried something symetrical and  even simpler - a 
> prototype object that rebroadcast's it's :POINT-STATE, :LAST-POINT-STATE,
> :ADJUST-SCREEN-POINT & :ADJUST-SCREEN messages to a pair of links.
> 
> I found I also had to redefine the :LINKS and :LINKED methods for
> scatterplot-proto to be able to link a pair of plots to this object.
> 
> ( code following .sig at bottom )
> 
> After linking the red and blue plots and selecting some points on
> one of them,  I get: 
> 
> (TEST-MAPPER-PROTO :ADJUST-SCREEN) 
> (TEST-MAPPER-PROTO :ADJUST-SCREEN) 
> (TEST-MAPPER-PROTO :ADJUST-SCREEN) 
> (TEST-MAPPER-PROTO :ADJUST-SCREEN) 
> (TEST-MAPPER-PROTO :ADJUST-SCREEN) 
> Error: no slot by this name - HARDWARE-ADDRESS
> Happened in: #<Subr: #f727ec>
> 
> 
> The problem I seem to be banging my head against in all of these
> attempts is that: 
> 
> (1) Linking is a protocol -- i.e. it's a complex interaction of 
> several messages, not a single method. 
> 
> (2) This protocol is not correctly or completely documented, and
> parts of it seem to depend on the internal implementation of graphic
> plots. 
> 
> (3) Although the tools are there to write a completely new and
> different linking protocol,  what I want is HALF A PROTOCOL --
> I don't want to change the linking strategy for plots ( and break
> other code that depends on that protocol ) -- I just want to write
> a different objects that responds to that protocol. 
> 
> (4) Even if I try to rewrite the entire linking protocol, I seem
> to still run into the problem of distinguishing how much is enough - 
> Linking interacts with selection and state, and some of my earlier
> failures were attempts to do this on a lower level that also kept
> running into HARDWARE-OBJECT problems. I don't have a map of where
> these protocols end in opaque implementation dependent HARDWARE
> OBJECTS with some internal state that wants to be tickled. 
> 
> 
> -- Anyone have a clue as to what I can do ? 

Linking is a protocol for communicating between active graphs (objects
that inherit from graph-proto). Most of the protocol is public and can
be customized. Part of it is currently private. Originaly this was
primarily for efficiency reasons.

There are two aspect of the protocol:

	1) Determining which plots are linked

	2) Propagating changes to point states between plots

Let's look at these in turn.

1) Determining who is linked is handled by two messages, :linked and :links.

	(send p :linked) returns T if p is linked, NIL if not.
	(send p :linked t) links p
	(send p :linked nil) unlinks p

	(send p :links) returns nil if p is not linked. If p is linked, it
	should return a list of all plots linked to p. The list may,
	but need not, include p. Must set internal state by
	call-next-method

Any implementation of these two methods that satisfies this
description will work. The :linked method is used by the standard menu
item for turning linking on and off.

2) This is the more complicated part. There are several ways to make
changes to point states that need to be propagated. You can use the
mouse, certain menu items, or the :point-state message. (The
:point-state message is a programatic way of accomplishing a state
change that should be propagated to all linked plots. It is not a
low-level mechanism for adjusting the internal states of pointsin
individual plots.) The state propagation process does the following:

	Find the list of linked plots with the :links message

	For each point with indez i changed in a single operation

	    for each linked plot q where the current point state of
		point i does not match the new state

		a) Adjusts the internal state of point i in plot q
		and record the previous state. (The mechanism is
undocumented. It happens to
		currently use knowledge of the implementation of the
		internal state when a graph is active. This is mostly
		for efficiency reasons that are no longer of
		importance. It could now be done using an internal
		message, maybe called something like
		lisp-stat::adjust-internal-point-state. Insuring that
		linking is only applied to children of graph-proto
		that are active makes sure this will work -- the set
		of objects to which linking is applicable is part of
		the protocol.)

		b) sends each linked plot the :adjust-screen-point
		message with the index of the changed point as argument.
		This allows each plot to redraw the point.

	Sends each linked plot the :adjust-screen message.
	
You can customize the linking process by redefining the
:adjust-screen-point or :adjust screen methods. Changing the
:adjust-screen-point method gives finer control and may provide a
better visual effect by allowing changes to flow through all all plots
simultaneously. But performance can be aproblem if each change is of
significant size. Changing :adjust-screen is usually simpler and
adequate for most purposes. It can have less desirable visual results
-- changing one plot at a time can produce a distracting wave artifact
that jumps from one plot to another.



There are two places at wich you can modify the linking process: at the individual point level