From: Ken McIvor [mailto:mcivor@…612…]
To: Henshaw, Andy
... snipped
It sounds you'd like to see a library with a simplified API
that supports most kinds of plots while letting users edit
things like the axes title, line width, number of histogram
bins, etc. Am I correct?
Exactly right.
... snipped
I would definitely go with introspection and declarative
programming. First, come up with a reasonable object picking
algorithm (see the `object_picker.py'
example). Let matplot manage all of the plot objects' data
(axes title, line style, edge color, etc). Use declarative
programming to define the editable parameters for each
object. Finally, use introspection to map between type of
the object and the list of editable parameters. PEP 246
adaption might be useful here, since it would let you break
the tight coupling between types and their parameters:
Thanks! I'll look at that.
... Code snipped
It might be a good idea to bug John about matplotlib
transitioning to using the Traits package from Enthough,
which would take care of managing the object parameters for
you. They developed it for use in their Chaco plotting
library, which went MIA shortly after release.> I'd like the plot to appear simple (by default), but with suitable
> access (perhaps triggered by mouseover?) to hidden features like a
> toolbar, scrollable axes, crosshair cursors (with
coordinate readout),
> and zoom controls.A toolbar that pops up via mouseover would be pretty
impressive, but I can't think of a way to implement it off
the top of my head. I'm not sure what you mean by
"scrollable axes". Do you mean pannning, the way pylab plots work?
In most cases, yes. Although, sometimes, I'd rather have a scrollbar
associated with an axis, particularly when I have data that is recorded
versus time. The scrollbar provides a context for how much of the data
set is currently visible and thumbtracking provides a fast way to scan
through it. But, I can live without that. I can imagine that it would
be clumsy to provide, in the general case.
Crosshair cursors are easy and coordinate readout are pretty
easy and I believe they already work in both MPlot and WxMpl.
Likewise zoom controls.
Right, I'd just like to hide it all when the user isn't interacting with
the panel.
> I'm certainly willing and able to contribute to this
development. I'm
> conflicted as to which code base to begin with, however.I'm not sure what to recommend. Merging MPlot and WxMpl so
that MPlot uses WxMpl for rendering and plot-level user
interactions like zooming would be one way to start. I think
you'd probably be better off going with a more dynamic
approach to parameter editing, since it would be a bit more
work up front but a lot less work to add plot types. If done
right, the object picking and parameters stuff could even be
backend independent.
Yes, I'd really like to get away from building static dialog boxes.
Ideally, we wouldn't have to touch this layer, even when MPL added
features.
Having the "object picking and parameter stuff" be backend independent
was not in my original thoughts, but, if it is doable, I can see that it
would be the best approach.