Re: [Plplot-devel] Should plgetpos be part of the common API or plP_gvpd and plP_gvpw?

[Maurice L. <mj...@ga...>]

As Geoff mentioned, something very similar to this is already being done at
some places in the code.  E.g.

x01c calls plGetCursor (plpage.c), to get world coordinates of mouse click

plGetCursor calls plTranslateCursor (plpage.c)

plTranslateCursor employs basically the same logic as pl_getpos, except in
a loop over windows.

So I suggest ripping out the core logic from plTranslateCursor and putting it
into a common API function, say c_plgetpos, that returns x & y world
coordinate values given device values, and a status code.  Then you could
call that from both pl_getpos and plTranslateCursor.

Alan W. Irwin writes:
 > Alexandre Gobbo and friends have suggested some python API as follows:
 > 
 > static char doc_getpos[]="transforms window coordinates into graphic coordinates";
 > 
 > static PyObject * pl_getpos(PyObject *self, PyObject *args)
 > {
 > 	PLINT x,y;
 > 	PLINT inside=1;
 > 	PLFLT xmin,xmax,ymin,ymax;
 > 	PLINT w,h;
 > 	PLFLT posX, posY;
 > 	PLStream *pls;
 > 
 > 	PyObject *result;
 > 	TRY (PyArg_ParseTuple(args, "iiii", &x,&y, &w,&h));
 > 	plgpls(&pls);   // pls points directly to a structure PLStream
 > 
 > 	xmin=pls->vpdxmi*(PLFLT)w;
 > 	xmax=pls->vpdxma*(PLFLT)w;
 > 	ymin=pls->vpdymi*(PLFLT)h;
 > 	ymax=pls->vpdyma*(PLFLT)h;
 > 
 > 	if      ((x < xmin)||(x > xmax)||(y < ymin)||(y > ymax)) inside=0;
 > 
 > 	if      (x < xmin)	x=(PLINT)xmin;
 > 	else if (x > xmax)	x=(PLINT)xmax;
 > 	if      (y < ymin)	y=(PLINT)ymin;
 > 	else if (y > ymax)	y=(PLINT)ymax;
 > 
 > 	posX=  pls->vpwxmi + (((PLFLT)x-xmin)*(pls->vpwxma-pls->vpwxmi)/(xmax-xmin));
 > 	posY=  pls->vpwyma - (((PLFLT)y-ymin)*(pls->vpwyma-pls->vpwymi)/(ymax-ymin));
 > 
 > 
 > 	result = Py_BuildValue(PL_ARGS("(idd)", "(iff)"),inside, posX, posY);
 > 	return result;
 > }
 > 
 > w, and h (width and height from the pyqt GUI environment) and x and y are
 > supplied, and the flag "inside" and  posX and posY are returned.
 > 
 > I want to discuss some alternatives to this approach here because I am
 > allergic to special PLplot API for each individual front end.
 > 
 > So here is one question I would like you to consider.  Would this general
 > functionality be useful for the common API for other GUI's?  If so, I would
 > strip all the python stuff out and make it generally available as common API
 > and then add a python wrapper to this new common API so Gobbo et al.
 > would have access to it from python.
 > 
 > If not generally useful, then I will suggest they do this logic in python
 > using the values of pls->vpdxmi, etc., and pls->vpwxmi, etc. returned from
 > the PLplot environment.
 > 
 > Before looking at how to retrieve the values, I have looked carefully at how
 > these values are set for the PLplot environment.  pls->vpdxmi, etc. are
 > generated in either c_plsvpa (called from c_plenv) and c_plvpor, and
 > pls->vpwxmi, etc. are generated by c_plwind (called on its own or from
 > c_plenv).
 > 
 > These values are retrieved from the PLplot environment using the plP_gvpd
 > and plP_gvpw functions.  Currently these functions are part of the public C
 > API, but are meant for internal PLplot use and are not currently part of the
 > common API.
 > 
 > So if some overall functionality like the C part of the code above does not
 > become part of the common API with a python wrapper, then instead I would
 > convert plP_gvpd and plP_gvpw to common API, and provide python wrappers.
 > 
 > Which choice is better?
 > 
 > 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

-- 
Maurice LeBrun    mj...@ga...