From: Maurice L. <mj...@ga...> - 2002-02-28 00:35:23
|
I don't really think the return code should be overloaded with window number. To me it's better/clearer to put it in a separate PLGraphicsIn struct entry. As for Geoff's comment, plots that go beyond the simple single-plot / subwindow model are indeed a problem. Although right now we do not number the windows created, we do "register" them with the plP_swin call at the end of plwind(). I added this ages ago with the hopes of supporting per-window operations from plrender for apps that handle their own windowing. Anyway, we could add the window defn at that point to a per-page list of windows, which is searched through for input events. Then return a window index in the PLGraphicsIn struct. Would need an API call to return the current window list too. Maybe best to just punt on it for now, but keep it in mind for a future project. Return a window number parameter in the PLGraphicsIn that for now is just a subpage number, but in the future may be a more generalized window number (making sure the two are compatible). Geoffrey Furnish writes: > 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. > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Maurice LeBrun mj...@ga... |