Menu
▾
▴
Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)
|
From: Alan W. I. <ir...@be...> - 2002-02-27 23:44:20
|
The new common API function c_plcalc_world (note the name change) can have any API it likes since this is a new function. So the goal there is to be the best possible API. Now my understanding is that common API functions are all void, i.e., the only way they return status information is via the argument list. For now I am going to return (via the argument list) a window value starting at zero with a window value of -1 indicating failure to find a valid window. I am no API expert so if that is the wrong way to go from the best possible API point of view let me know, and I will change it. But the API for this function is a completely separate issue from the plTranslateCursor API. For now, I will leave the plTranslateCursor API strictly as is, but I will change its internals to call c_plcalc_world. Once consensus has been reached on changing the plTranslateCursor API, then all data returned from c_plcalc_world will be available to plTranslateCursor to facilitate that changed 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, Joao Cardoso wrote: > On Wednesday 27 February 2002 5:03 pm, Alan W. Irwin wrote: > > 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? > > My suggestion was intended to avoid this API break. However, I don't think > that it would confuse users. Many standard C library functions are expected > 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 world > coordinates is possible. > > With this approach I thing that most code would still work without > modifications; x01c will. > > If you think that this is not reasonable, them the PLGraphicsIn structure > could contain one more field, the subwindow number; existing code will still > 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 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. > > > > 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, 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 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 > > > | __________________________ > > > | > > > | > > > | _______________________________________________ > > > | 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 > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
