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

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

On Wednesday 27 February 2002 5:03 pm, Alan W. Irwin wrote:
> Using the return value in two different ways is a little awkward becaus=
e 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 h=
ow
> about just changing the API?

My suggestion was intended to avoid this API break. However, I don't thin=
k=20
that it would confuse users. Many standard C library functions are expect=
ed=20
to return e.g. a pointer on sucess or NULL to indicate failure.

Currently, plGetCursor() comments say:
 Returns 0 if no translation to world coordinates is possible.

I would propose that it says:
 Returns the subwindow number, starting at 1, or 0 if no translation to w=
orld=20
coordinates is possible.

With this approach I thing that most code would still work without=20
modifications; x01c will.

If you think that this is not reasonable, them the PLGraphicsIn structure=
=20
could contain one more field, the subwindow number; existing code will st=
ill=20
work, but should be recompiled.

>  It is possible this might hurt some of our
> users since it is public API, but I feel this is not too likely since i=
t is
> not part of the documented common API.
>
> If we agree that it is okay to change the API, I am thinking of returni=
ng
> 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 wh=
ere
> "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 th=
e
> 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 t=
o
> 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 i=
t
> works I will commit it subject to change if anybody has some API ideas
> in the meanwhile.
>
> Alan
>
> email: ir...@be...
> phone: 250-727-2902=09FAX: 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, Joao Cardoso wrote:
> > On Wednesday 27 February 2002 04:07, Alan W. Irwin wrote:
> > | I would appreciate further discussion of one aspect of the
> > | plTranslateCursor code.
> > |
> > | It goes through a reversed list of windows (I assume these are
> > | sub-windows?) and for the first one where the cursor is inside the
> > | sub-window it does the transformation and returns.
> > |
> > | If I have this interpretation right, then it looks like the pyqt
> > | group's plgetpos using data in the PLStream struct won't really
> > | work since on a page with subwindowing, the world coordinates can
> > | vary wildly form sub-window to sub-window (e.g., example 1), and
> > | their code doesn't take account of this.  So my guess is they are
> > | going to be forced (by example 1) to go to the plTranslateCursor
> > | type of transformation.
> >
> > One problem with plGetCursor() is that it doesn't give information on
> > which sub-page the mouse event occurred. I always found this a
> > serious limitation.
> >
> > Perhaps using the "i" variable as the return value from
> > plGetCursor()? of course existing code that relies on a "1" to be
> > returned would fail, but I guess that most code is just checking for
> > a zero/non-zero return value. An advantage of this approach is that
> > it wouldn't break API compatibility.
> >
> > Joao
> >
> > | Do you agree?
> > |
> > | Alan
> > |
> > | email: ir...@be...
> > | phone: 250-727-2902=09FAX: 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
> > | __________________________
> > |
> > |
> > | _______________________________________________
> > | Plplot-devel mailing list
> > | Plp...@li...
> > | https://lists.sourceforge.net/lists/listinfo/plplot-devel
> >
> > _______________________________________________
> > Plplot-devel mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel