From: Maurice L. <mj...@br...> - 2007-05-21 07:36:43
|
Alan W. Irwin writes: > However, your general comments on interactive PLplot struck a nerve with me. > In my opinion where PLplot does very poorly on the interactive front is the > severely limited interactive GUI devices that have been implemented so far. > For example, the -dev gcw "GUI" allows selection of pages to display, and > that is about it. -dev tk is our most extensively developed GUI for PLplot > at the moment. It has zooming capability, a colour pallette adjustment, and > perhaps even cursor capability. (I know that -dev xwin has cross-hairs [or > cursor] capability. However, I have forgotten how to fire it up and IIRC, > the world coordinates of the cross-hairs are printed out rather than > returned to the calling routine which is sort of useless. I think -dev tk > may have the same limited cursor capability as well). A callback has been supported virtually since I first implemented this. From src/plcore.c: /* Set the function pointer for the keyboard event handler */ void plsKeyEH(void (*KeyEH) (PLGraphicsIn *, void *, int *), void *KeyEH_data) { plsc->KeyEH = KeyEH; plsc->KeyEH_data = KeyEH_data; } This is one of the few interactive capabilities that's available from the core API, i.e. attempts to be fairly generic. Unfortunately it's not currently demo'ed from any of the example programs. > In my opinion what is truly needed for interactive plotting capability is > full cursor capability where the world coordinates of the cursor when a > keyboard key was struck _and_ the identity of that key are returned from the > device to the PLplot library and then back to the routine calling the PLplot > library. Currently no PLplot API exists for returning full cursor data, but > it should be straightforward to extend the API appropriately with plgcursor. > Such a function should make an interactive device wait until the user > struck a key and then the function would return the x, y, (and z?) world > coordinates of the cursor position when the key was struck as well as the > identity (X keycode) of the key that was struck. I don't understand this objection, b/c AFAIK if you want to poll, plGetCursor does the job fine. Run your handy neighborhood x01c using -locate (w/X or TK driver). It returns the necessarily device-independent version of the keyboard info, in a PLGraphicsIn (defined in plcore.h), which is: typedef struct { int type; /* of event (CURRENTLY UNUSED) */ unsigned int state; /* key or button mask */ unsigned int keysym; /* key selected */ unsigned int button; /* mouse button selected */ PLINT subwindow; /* subwindow (alias subpage, alias subplot) number */ char string[PL_MAXKEY]; /* translated string */ int pX, pY; /* absolute device coordinates of pointer */ PLFLT dX, dY; /* relative device coordinates of pointer */ PLFLT wX, wY; /* world coordinates of pointer */ } PLGraphicsIn; The MOST powerful interactive way to run plplot is actually via a plframe. That's a full-fledged TK widget, embedded in a TK application. If you want input info, just set up key bindings. Keep or override the default plframe behavior as needed. The full power (and specificity) of the TK toolkit is available. Of course, this area like any could use some additional work. It would be nice to see the interactive capabilities of plplot continue to improve. The interactive aspects are one thing that IMO sets it apart from some other free packages. More drivers / embeddable-widgets that have features comparable to that available in plframe would give additional impetus for refactoring common functionality into the core, which would (hopefully) benefit all interactive drivers. -- Maurice LeBrun |