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

[Alan W. I. <ir...@be...>]

On Mon, 4 Mar 2002, Maurice LeBrun wrote:

> 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.
> \*--------------------------------------------------------------------------*/

Thanks for pointing out that documentation in the xwin driver.

Maurice, you are more expert than me on these kind of questions so I am
tempted to just go along with your vision of supporting 3 separate locate
modes at the device level.  But my gut instinct tells me that the device
level should be making minimum decisions. Instead, my view is it should pass
back data to the PLplot library level in sufficiently general form so that
the decisions (possibly including the 3 options above) could be done in that
more centralized place. I believe we should discuss simplifying the device
level handling of locate mode because it makes it much easier to have the
same minimum locate mode behaviour for all interactive drivers that support
it. Furthermore, once we decide on what parts can be done at the PLplot
library level versus what must be done at the device level (even if that
turns out to be the status quo for what goes on with the xwin device driver
now), then we should document the device driver requirements, and review
each interactive driver to make sure it provides what is required.

>
>  > 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. :)

Yes.  ;-) But I want to emphasize we should take the general approach of
having common interactive API that is simple for every front end to wrap.

In your opinion, is such a common API (with variables and arrays in argument
lists as opposed to structs) straightforward to write based on our current
public (as opposed to common) API for locate mode?  If so, I am willing to
write such a common API, but of course I would probably need a lot of help
from you.

>
>  > 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.

Sorry for my poor choice of words here.  Drop the "coherent" from above.

>
> 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...
>