Re: [zzdev] Two applitude programmer's questions

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

On Mon, 31 Jul 2000, Benjamin Fallenstein wrote:
> 
> > > - When my raster is the current raster in the right view, and the view's
> > > cursor is moved, I want to move the cursor of the left view in some
> > > custom way. How can I do this?
> > 
> > > The idea behind the latter is that I want to move the left cursor to
> > > some list (doesn't need to be a common list) of items of the type of the
> > > item selected in the right view; this should speed up my point-and-click
> > > programming system.
> > 
> > Are you sure this wouldn't be easier to do by creating two wholly new
> > views whose cursors are locked using cursor-cargo?
> 
> Yep. The left view needs to be set to a cell evaluated from the *type*
> of the token selected in the right view -- that's a lot of indirection,
> which needs to be coded. (Besides, it's a design decision for my
> applitude that it should use the existent views, if possible, to make it
> consistent with the rest of the system.)

That's not necessarily impossible: it might be possible that being able to
insert a "filter" before a ZOb raster could be useful. The filter could
change what the ZOb raster actually sees.

> > If not, then it may be time for cursor magic: a dimension on the cursing
> > cell which indicates routines to run when he cursor is changed. This would
> > be started by ZZCursorReal, which then must be made the only way in which
> > cursors are moved.
> 
> Do you mean the only way *real* cursors are moved, or do you mean the
> virtual cursors should be removed? I don't see a reason for the latter.
> After all, I need to watch a real cursor, not a virtual one. Should we
> use d.trigger as the dimension or d.cursor-trigger (or something the
> like)? I vote for the latter, because I think d.trigger should be
> reserved for changes in the content of cells.

The former. Virtual cursors are a useful speed hack internally. Agreed
also on the latter. Then there's just the problem of the actual running:
where do we get the context from (both ZZPrimitiveActions and Clang use
context a lot). Possibly start with a clean virtual context.

The function call should look for stuff in modules just like rasters.

	Tuomas