Hi Hazen,
As you suggested, I am going to put this thread on plplot_devel because it
will probably be of interest to the other developers there.
On 2007-05-16 23:18-0400 Hazen Babcock wrote:
On May 16, 2007, at 12:30 AM, Alan W. Irwin wrote:
[...]Speaking of which, do you have any near-term plans for xwinttf or the
further Cairo devices you proposed?
Near term? I'd like to finish this project up in the next few months and
hopefully I can find the time. My plan is to put xwinttf and all the other
Cairo drivers into one file, probably cairo.c, as was done for the GD
driver.
Note, the proposed cairo-based devices would belong both to the PLplot
display device driver family (xwinttf and others?) and to the PLplot
output file device driver family (postscript, and others). For a discussion
of those two families of devices see
http://plplot.sourceforge.net/docbook-manual/plplot-html-5.7.3/x-drivers.html
and
http://plplot.sourceforge.net/docbook-manual/plplot-html-5.7.3/output-drivers.html.
Since display device drivers potentially have interactive considerations to
take into account (how to move from one page to the next, full cursor
capability [see below], and other GUI considerations) and output device
drivers do not, I suggest you split the proposed cairo-based set of devices
into two separate drivers (one for display devices and one for file output
devices) with two separate files for the source.
I'm not sure how to proceed with the xwinttf driver regarding the
interactivity issues that you mentioned. We could make it behave the same as
the xwin driver, i.e. only use one window and keep clearing after each plot,
but this is not ideal for interactive environments, such as Perl / PDL
where it is nice to be able to keep a couple plotting windows open, even if
you might not be able to update them. On OS-X the operating system takes care
of keeping them updated when you cover them with another example or whatever,
so they don't even need to handle refresh events.
I've come to believe (perhaps incorrectly?) that one of the major
shortcomings of PLplot is that it is difficult to use in an interactive
environment. The library only supports output to one stream at a time and
even if it did support multiple streams the stream is an internal structure
in the library, you can't even get an generic pointer to it so that you could
cache it, draw something else, and go back to drawing the original plot.
Note, you can randomly switch between various streams using the
plsstrm command (see the 14th example). And the device driver interface is
written generally enough (with an escape function) so that devices can have
a tremendous amount of capability.
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).
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 well recall a spectrum analysis programme I used extensively in the early
80's whose plotting device drivers had that full cursor capability which
allowed an application that used the library to have a very large menu of
possible transformations or measurements of the spectrum being plotted
depending on where the user placed the cursor and what key was struck.
I have a potential interactive research software project that would require
exactly such an approach. I have put off the project in favour of other
research projects for a number of reasons. But one of those reasons is I am
currently not allowed to implement that project software with PLplot because
no PLplot GUI devices currently have the full cursor capability that I
