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

[Joao C. <jc...@fe...>]

On Wednesday 27 February 2002 6:25 pm, Geoffrey Furnish wrote:
> Alan W. Irwin writes:
>  > Using the return value in two different ways is a little awkward bec=
ause
>  > I believe the first sub-page is numbered zero rather than one.  We c=
ould
>  > return i+1 but that could lead to all sorts of misunderstandings.  S=
o
>  > how about just changing the API?  It is possible this might hurt som=
e 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 succe=
ss
>  > or failure as before.  But I am no API expert so any other suggestio=
ns
>  > 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 nu=
mber
>  > 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 fro=
m a
>  > PLGraphicsIn struct to the simple input variables of c_plgwc on inpu=
t
>  > and the reverse on the returned variables.
>  >
>  > I intend to implement these ideas right away, and after checking tha=
t it
>  > works I will commit it subject to change if anybody has some API ide=
as
>  > 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.

I don't think this to be very likely... but one can never guess what user=
s=20
will do (need). That's why I think that returning the subwindow will be=20
enough for most applications; users with special needs will learn that=20
clicking in the legend is a "feature" not yet supported, and will avoid u=
sing=20
it. This is perhaps too pragmatic, but as you say bellow, we don't store=20
viewport info.

In my personal case, I plot the legend bar for shade and contour plots in=
side=20
the main plot, which make things worse than for you (but I have an iterat=
ive=20
legend placement utility, to manually move the legend position away of=20
interesting regions).

But this issue raises some future (possible) development compatibility=20
problems, and as such I think that is better to just add a field to the=20
PLGraphicsIn structure to indicate the subwindow number (instead of using=
 the=20
function return value for this--see my other post); latter, another field=
=20
could be added to also indicate the viewport.

Joao

>  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.
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel