Re: [Plplot-devel] Locate mode improvements, (was Other problems with -locate option on x01c)

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > (1) Currently, there are actually two kinds of locate mode. One of them
 > ("driver" locate mode) prints out x and y, but otherwise does not allow the
 > data to be retrieved by the programme. The other ("user" locate mode) does
 > allow programme access to the data, but it is only available from the C front
 > end.

Actually 3 kinds.  The third is when the user provides a locate handler, to
take the place of the default handler.

The best place to look for info on this stuff really is the source code.
Stuff I personally have written is often very well commented, because 
it's a lot better than nothing when there's no time to write real
documentation.  An example from xwin.c:

/*--------------------------------------------------------------------------*\ 
 * Locate() 
 * 
 * Handles locate mode events. 
 * 
 * In locate mode: move cursor to desired location and select by pressing a 
 * key or by clicking on the mouse (if available).  Typically the world 
 * coordinates of the selected point are reported. 
 * 
 * There are two ways to enter Locate mode -- via the API, or via a driver 
 * command.  The API entry point is the call plGetCursor(), which initiates 
 * locate mode and does not return until input has been obtained.  The 
 * driver entry point is by entering a 'L' while the driver is waiting for 
 * events.   
 * 
 * Locate mode input is reported in one of three ways: 
 * 1. Through a returned PLGraphicsIn structure, when user has specified a 
 *    locate handler via (*pls->LocateEH). 
 * 2. Through a returned PLGraphicsIn structure, when locate mode is invoked 
 *    by a plGetCursor() call. 
 * 3. Through writes to stdout, when locate mode is invoked by a driver 
 *    command and the user has not supplied a locate handler. 
 * 
 * Hitting <Escape> will at all times end locate mode.  Other keys will 
 * typically be interpreted as locator input.  Selecting a point out of 
 * bounds will end locate mode unless the user overrides with a supplied 
 * Locate handler. 
\*--------------------------------------------------------------------------*/ 

 > The driver locate mode in its present form is not useful for my needs
 > because my programmes need access to the locate-mode data (x and y and
 > especially the key or mouse button that was pressed since that allows the
 > user to enter a wide variety of commands to help in interactive reduction of
 > spectra).  The user locate mode sounds more promising in that respect, but
 > it needs to make x, y, and key available to all front ends (i.e., probably
 > python in my case). Following what currently is possible with driver locate
 > mode, you should be able to enter or leave user locate mode at will by
 > pressing the appropriate keys, i.e., it should be available for all examples
 > for all front ends if an interactive driver with the right capabilities is
 > specified.

I agree, this one needs to be better supported in the bindings.  Sounds like
you'll be doing the python binding. :) I had planned on eventually adding some
kind of menu support from the TK driver, but it never materialized.. I guess I
haven't really needed it yet.

 > Thus, what I am really pressing for is a single coherent locate mode that

I don't see anything incoherent about it fundamentally.  The docs, yeah, and
a tutorial wouldn't be a bad idea.  

There is a default locate behavior without the user having to do a thing but
press "L" and start clicking away.  There is a way to invoke locate explicitly
from the [C/C++] API's.  And a way to replace the low-level locate handler.
I believe these are all well-considered features of the locator support.

 > combines the best features of our two present locate modes plus a bit more.
 > I really need these improvements if I am going to use interactive PLplot for
 > my next research project, but there may be other improvements to locate mode
 > that we need to discuss as well so I would welcome such discussion.

-- 
Maurice LeBrun    mj...@ga...