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

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

Some of the confusion here is that the documentation talks about sub-pages,
sub-windows (which I think are the same thing) and lots of different kinds
of coordinates (some of which are the same).  And now Geoffrey has brought
multiple viewports to our attention.  (Thanks, I think....;-))

From the documentation:

Viewports are created within the current subpage. If the division of the
output device into equally sized subpages is inappropriate, it is best to
specify only a single subpage which occupies the entire output device (by
setting nx = 1 and ny = 1 in plstart or plstar), and use one of the viewport
specification subroutines below to place the plot in the desired position on
the page.

So my mental model of what is usually done is the arrangement of sub-pages
is set up by plssub (or equivalent plstart, etc.), and the actual sub-page
you are currently plotting to is specified by pladv.  Only after that
sub-page is specified would you set up possibly multiple (as Geoffrey has
indicated) viewports.

For now, I am going to go ahead with c_plcalc_world as is which will produce
the same functionality as before.  (I am assuming here that the sub-pages
discussed above are identical with the "windows" specified in the code.)

But from Geoffrey's argument below that functionality is broken for multiple
viewports on the same sub-page (or page if there is only one of them).  The
reason I say this is that different viewports will have different world
coordinates, and there doesn't seem to be any provision for that case in the
current code.

Geoffrey, could you please test the current functionality of plGetCursor (as
in example 1, but with your multiple viewports per page) to see what world
coordinates (if any) it returns for your multiple viewports?

Ultimately, I think we will have to change c_plcalc_world to deal with world
coordinates of multiple viewports, but I want to concentrate for now on
getting the current functionality replicated in the common API.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Wed, 27 Feb 2002, Geoffrey Furnish wrote:

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