Hi Alan, splitting up the PLGraphicsIn structure into its (relevant) components seems the easiest way to get all the language bindings to support the API. Most will then have a method to present a more convenient interface to the programmer (a structure or an object most probably).
As for retrieving the cursor location and possibly other things in Windows, that is definitely possible, but if I remember correctly, it is retrieved via specific events. It should not be that difficult to get hold of, although I do not know by heart how to do it, so some investigation is required. As for plMergeOpts and friends: They use a PLOptionTable struct, so some translation will need to be done. I do not know how SWIG takes care of that sort of things, but for the handcrafted interfaces an interface routines that takes a structure in one language and translates it into another is not too difficult to do and then any convenient convention for NULL would do. The character string array notes to plMergeOpts is less critical, it is simply a set of text strings, right? Perhaps more problematic is the fact that they should be static character strings, as the pointer to them is stored. Also the PL_OPT_FUNC type of options may present some issues, if the user wants to implement callback function in their programming language of choice. But perhaps we should take these hurdles one at a time. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:[email protected]] > Sent: Monday, March 24, 2014 11:19 PM > To: Arjen Markus > Cc: PLplot development list > Subject: Implementing locate mode for all bindings and interactive devices and > implementing plmergeopts for all bindings > > Hi Arjen: > > Thanks for responding to Moez' question on plplot-general concerning > interative > Fortran possibilities. I think we are all agreed with the two goals you > stated of > having interactive support for all our language bindings and each of our > interactive > devices. And it is also pretty clear we need to implement plmergeopts for > all our > bindings. So I would like to start discussion here of all three of those > topics. > > 1. Interactive support for all our language bindings. > > The fundamental issue here is the argument of plGetCursor is a pointer to a > PLGraphicsIn struct, and C structs like that are not supported by most > languages > we support now. For example, although plGetCursor does appear to have a > binding > for the Octave case, that function is completely ignored for the rest > (Python, Java, > and Lua) of our swig-generated bindings, and I assume it is also ignored for > most/all > of our bindings that are not generated by swig. > > So I think the best way forward here is to define a (c_)plgcursor function > which > wraps plGetCursor and whose arguments are a list of PLINT and PLFLT pointers > to > all the kinds of information currently contained in the PLGraphicsIn struct. > If > everybody is in agreement on that general approach, then it should be > straightforward to propagate the proposed (c_)plgcursor function to all our > language > bindings. > > 2. Interactive support for the PLESC_GETC escape code for each of our > interactive > devices. > > I did my own survey of our important interactive devices, and (in agreement > with > what you said on plplot-general) I think the only important interactive > device missing > this capability is the wingcc driver. > > @Argen: does the Windows API used for the wingcc device support the > possibility > of returning cursor information? If so, getting this device up to speed with > the > remaining interactive devices should be straighforward. > > 3. Implementation of (c_)plmergeopts and propagating it to all bindings > > Topics 1 and 2 discuss the changes needed to support the locate mode in > example > 1 for all bindings and for each of our interactive devices. > But that brings up a related issue which is that we should also have complete > language bindings for plMergeOpts (renamed to (c_)plmergeopts as appropriate > for > a function in our public API). This would allow us to use the -locate option > for > example 1 in any language. > > This should be straightforward except for one issue which is that both the > first and > 3rd arguments to plMergeOpts are currently arrays of _either_ pointers to > strings > _or_ NULL. Languages support NULL arguments in a wide variety of ways (if they > support them at all). So I think a much better thing to do would be to drop > that > second alternative and instead use the empty string (a concept supported by > all > languages) for the same purpose as the current NULL. > > Question for those here who are familiar with use of plMergeOpts, and all the > argument parsing. Is there any reason not to use the empty string this way? > For > example, would an empty string have a normal use which would preclude using > it as > a substitute for the current NULL which is used to mark holes in the options > table as > well as the final array element. > > In any case, once we arrive at consensus on how to deal with this issue, the > implementation should be straightforward. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation for > stellar interiors (freeeos.sf.net); the Time Ephemerides project > (timeephem.sf.net); > PLplot scientific plotting software package (plplot.sf.net); the libLASi > project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the > Linux > Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
