RE: [Matplotlib-users] advice on writing an application

[<And...@gt...>]

> From: Ken McIvor [mailto:mc...@ii...]=20
> To: Henshaw, Andy
>=20
... snipped
>=20
> It sounds you'd like to see a library with a simplified API=20
> that supports most kinds of plots while letting users edit=20
> things like the axes title, line width, number of histogram=20
> bins, etc.  Am I correct?

Exactly right.
... snipped
>=20
> I would definitely go with introspection and declarative=20
> programming.  First, come up with a reasonable object picking=20
> algorithm (see the `object_picker.py'=20
> example).  Let matplot manage all of the plot objects' data=20
> (axes title, line style, edge color, etc).  Use declarative=20
> programming to define the editable parameters for each=20
> object.  Finally, use introspection to map between type of=20
> the object and the list of editable parameters.  PEP 246=20
> adaption might be useful here, since it would let you break=20
> the tight coupling between types and their parameters:

Thanks!  I'll look at that. =20

... Code snipped

> It might be a good idea to bug John about matplotlib=20
> transitioning to using the Traits package from Enthough,=20
> which would take care of managing the object parameters for=20
> you. They developed it for use in their Chaco plotting=20
> library, which went MIA shortly after release.
>=20
> > I'd like the plot to appear simple (by default), but with suitable=20
> > access (perhaps triggered by mouseover?) to hidden features like a=20
> > toolbar, scrollable axes, crosshair cursors (with=20
> coordinate readout),=20
> > and zoom controls.
>=20
> A toolbar that pops up via mouseover would be pretty=20
> impressive, but I can't think of a way to implement it off=20
> the top of my head.  I'm not sure what you mean by=20
> "scrollable axes".  Do you mean pannning, the way pylab plots work?=20

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=20
> easy and I believe they already work in both MPlot and WxMpl.=20
>  Likewise zoom controls.

Right, I'd just like to hide it all when the user isn't interacting with
the panel.
>=20
> > I'm certainly willing and able to contribute to this=20
> development.  I'm=20
> > conflicted as to which code base to begin with, however.
>=20
> I'm not sure what to recommend.  Merging MPlot and WxMpl so=20
> that MPlot uses WxMpl for rendering and plot-level user=20
> interactions like zooming would be one way to start.  I think=20
> you'd probably be better off going with a more dynamic=20
> approach to parameter editing, since it would be a bit more=20
> work up front but a lot less work to add plot types.  If done=20
> right, the object picking and parameters stuff could even be=20
> backend independent.
>=20

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. =20

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.