PLplot

On Thursday, August 30, 2012 at 09:28:49 (-0700) Alan W. Irwin writes:
 > On 2012-08-30 02:26-0700 Jerry wrote:
 > 
 > > Does the Tk interactive method allow the user to use a mouse to
 > interactively select a rectangular portion of the plot for zooming?
 > This would certainly be useful and then I would have an actual
 > personal interest in this work. Do any of the interactive devices
 > allow this? X, Aquaterm and Qt do not--those are the only ones that I
 > have tried.

Any Tcl/TK application using a "plframe" widget, that is, plplot-enhanced
frame, can do zoom & pan, palette modifications, orientation swaps, margin
adjustments, save to file.  All very handy stuff.

 > This question introduces a new topic, so I am using a different subject
 > for it.
 > ...
 > Note that high-level interactive use has to be programmed at the
 > application level.  [snip]
 > 
 > Note, some higher-level interactive capability (zooming) has already
 > been implemented for our tk device, but that would potentially
 > interfere with implementation of higher level interactivity in
 > applications like I have just described.  So I definitely don't want
 > to see, e.g., zooming capability implemented for all our interactive
 > devices.  On the other hand, I do want to see the fundamental
 > interactive capability available for all our interactive devices so
 > we do need a volunteer to add mouse button/key identification for
 > -dev qtwidtet.

As long as the default behavior can be overridden by the user, I see no issue
with implementing more default interactive capabilities.  For example when we
were at Lightspeed, Geoffrey & I implemented an interactive scalable renderer
on top of plframe.  We were able to override the default keystroke bindings
and menu accessors in order to take full control of the zoom/pan behavior.  In
so doing we were able to zoom to something like 10,000x magnification without
undue performance penalties, since our rendering engine would omit as many
plot elements that were off-screen as possible.  An additional speedup was to
only include microscopic details as they became visually relevant, i.e. on the
order of 1 pixel in size or more.

This was done using a stock plplot build, naturally.  IIRC, there were some
features that I'd like to see the plplot Tcl/TK have in support of such
efforts, such as being more library oriented for application writers.  However
no changes are absolutely necessary -- all you really need is the ability to
change existing key bindings or menu entries (straightforward enough in
Tcl/TK).  Granted, we were a bit "lucky" since such extensibility was never a
design requirement back when the plplot Tcl/TK support was written.  For
future efforts, it should be.

If I ever had the free time (ha) I'd like to code a demo.  Not that hard since
I've already done it but would take a bit of time to do from scratch.

-- 
Maurice LeBrun

On 2012-08-30 12:33-0500 Maurice LeBrun wrote:

> On Thursday, August 30, 2012 at 09:28:49 (-0700) Alan W. Irwin writes:
> > On 2012-08-30 02:26-0700 Jerry wrote:
> >
> > > Does the Tk interactive method allow the user to use a mouse to
> > interactively select a rectangular portion of the plot for zooming?
> > This would certainly be useful and then I would have an actual
> > personal interest in this work. Do any of the interactive devices
> > allow this? X, Aquaterm and Qt do not--those are the only ones that I
> > have tried.
>
> Any Tcl/TK application using a "plframe" widget, that is, plplot-enhanced
> frame, can do zoom & pan, palette modifications, orientation swaps, margin
> adjustments, save to file.  All very handy stuff.
>
> > This question introduces a new topic, so I am using a different subject
> > for it.
> > ...
> > Note that high-level interactive use has to be programmed at the
> > application level.  [snip]
> >
> > Note, some higher-level interactive capability (zooming) has already
> > been implemented for our tk device, but that would potentially
> > interfere with implementation of higher level interactivity in
> > applications like I have just described.  So I definitely don't want
> > to see, e.g., zooming capability implemented for all our interactive
> > devices.  On the other hand, I do want to see the fundamental
> > interactive capability available for all our interactive devices so
> > we do need a volunteer to add mouse button/key identification for
> > -dev qtwidtet.
>
> As long as the default behavior can be overridden by the user, I see no issue
> with implementing more default interactive capabilities.

Good point.

> For example when we
> were at Lightspeed, Geoffrey & I implemented an interactive scalable renderer
> on top of plframe.  We were able to override the default keystroke bindings
> and menu accessors in order to take full control of the zoom/pan behavior.  In
> so doing we were able to zoom to something like 10,000x magnification without
> undue performance penalties, since our rendering engine would omit as many
> plot elements that were off-screen as possible.  An additional speedup was to
> only include microscopic details as they became visually relevant, i.e. on the
> order of 1 pixel in size or more.

> [....]If I ever had the free time (ha) I'd like to code a demo.  Not that hard since
> I've already done it but would take a bit of time to do from scratch.

Such demonstrations of high-level interactive use of PLplot with Tk
and plframe would be quite useful.  Note we also have plotting GUI's
implemented for the GTK+ GUI (implemented using our cairo device
driver capabilities) and the Qt4 GUI (implemented using our qt device
driver capabilities).  The issue for those two additional GUI's,
however, is nobody has bothered to implement high-level plframe-like
interactivity for them yet.

Note I also don't want users to get the impression that GUI's
(graphical user interfaces) are the only way to obtain high-level
interactive capability for PLplot. So in addition I would like to see
emphasized with one standard C example (ported to all our languages)
and also mentioned in our DocBook documentation, that the low-level
capabilities (keystroke/mouse button id + position) of our interactive
devices means users can develop CLI (command-line interface)
applications written in any language supported by PLplot with as
high-level an interactive plotting capability as they care to
implement.

Of course, GUI's are prettier because there are a lot of widgets
available for any particular GUI platform such as Tk, GTK+, Qt, etc.,
that can be straightforwardly adapted to interactive plotting needs. 
But a CLI approach does have more interactive bandwidth for a touch
typist like me.  So, for example, I use a wonderful CLI mailer called
alpine (the successor to pine which was the successor to elm) to
handle my e-mail in a lightening quick way rather than fooling around
with relatively slow pointing and clicking you are forced to do with a
GUI mailer. (I brought up that example just to give full disclosure
about my natural prejudice toward the CLI side of things in the
perpetual CLI versus GUI debate. :-) )

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
__________________________