Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

[Geoffrey F. <fu...@ga...>]

Alan W. Irwin writes:
 > Using the return value in two different ways is a little awkward because I
 > believe the first sub-page is numbered zero rather than one.  We could
 > return i+1 but that could lead to all sorts of misunderstandings.  So how
 > about just changing the API?  It is possible this might hurt some of our
 > users since it is public API, but I feel this is not too likely since it is
 > not part of the documented common API.
 > 
 > If we agree that it is okay to change the API, I am thinking of returning
 > the window number in the argument list and returning success or failure as
 > before.  But I am no API expert so any other suggestions are welcome
 > especially if there is some obvious data structure where the returned
 > window number could be stored.
 > 
 > As far as the common API version is concerned (let's call it c_plgwc where
 > "gwc" stands for get world coordinates), I also intend to have a return of 1
 > for success and 0 for failure. Essentially it will be identical to the
 > current plTranslateCursor except it will have x and y "absolute" coordinates
 > as input, and world coordinates and window number as output rather than
 > assuming those data are accessible to/from a PLGraphicsIn struct.  The new
 > plTranslateCursor would then consist essentially of a call to c_plgwc with
 > an argument transformation from a PLGraphicsIn struct to the simple input
 > variables of c_plgwc on input and the reverse on the returned variables.
 > 
 > I intend to implement these ideas right away, and after checking that it
 > works I will commit it subject to change if anybody has some API ideas
 > in the meanwhile.

wheeee!  Well, I love to see prompt action, but I do have one concern
about what is being discussed in this thread.

I remember when Maurice and I first talked about this thing, years
ago, but the language that is being used in this thread does not match
up with what I remember we had talked about.  So either my memory is
wrong, or maybe somehow we never implemented what I wanted, or
something.  I dunno, it's been too long.

Anyway, my concern is that the "window", as in the "sub page window",
may not be the right--or maybe just not sufficient--info to return.  I
think we also need to return something about the viewport definition.
Many "windows" have more than one active viewport.  I /often/ make my
plots have two viewports, the "main" one where the plot goes, and an
additional one where the legend goes.  For example, on shade plots, I
may draw one big squarish region with the shaded data, and then a
little thin/tall bar on the left which shows the color map used in the
shade, with the y axis on this color bar being the function value
range in the main plot.

Now, if the user uses the locator and selects a coordinate, they might
be asking the interactive tool to tell them the world coordinates at
some point in the main picture area, but they might also be trying to
determine the value of some particular part of the legend box.  So, it
seems to me that to really do this right, you need to convert the
screen (pixel) coords to world coordinates, and return both the window
(sub page) and the viewport for which the match was found.

I think, reaching way back into the cobwebs, that the fly in the
ointment here is that we don't number the viewports.