Re: [Matplotlib-users] matplotlib user interface issues

[Gregory L. <gre...@ff...>]

> 1) Seems to me that repr for the plot objects could be blanked out for 
> interactive mode. Having python print out what it does now isn't 
> usually useful and in some cases (like error bars) leads to a dump on 
> the screen. Any reason not to make repr mode dependent (or at least 
> configurable)?
> 
> John pointed out that one of the worst offenders (error bars) actually 
> return lists of plot objects so it wouldn't do much good to override 
> repr for the plot objects unless one used a list object where repr was 
> overridden as well. The annoyance factor in interactive use is perhaps 
> sufficient to do this though. What do others think?

This has not really bothered me, but if this dissapear I will not be sad
either...so 0

> 2) Any support for being able to specify colors using more than single 
> character codes (say, using "red" or "green", and line styles and 
> symbols with more descriptive terms like "dashed". This is not in place 
> of the existing scheme, but as a more verbose alternative. Along those 
> lines, allowing something like:
> 
> plot(x1, y1, x2, y2, x3, y3, color=['red','green','blue'])

good idea, but I am well used to matlab shortcuts so +0

> 3) Tick control can be awkward if one simply wants to add an integral 
> number of minor ticks to the chosen major tick interval. Currently 
> using minor ticks forces one to access the plot objects, and specify 
> the major tick interval as well. It would be nice if one could just ask 
> for n minor ticks for each major tick interval by using the appropriate 
> keyword (name tbd). Some illustrations of possible alternatives:
> 
> plot(x, y, xmajor=5)
> plot(x, y, xmajor=5, xminor=1)
> plot(x, y, xminordiv=5) # 5 minor ticks per major regardless  of major 
> tick size
> 
> Generally, I expect that people set these interactively after plotting 
> without these options. When they see what is automatically produced, 
> this is a simple way of tweaking the plot without doing a lot of object 
> manipulation.

very good idea, +1: ticking adjustment is common before outputting a
figure for printing, and this will make this tinkering more easy...

> 4) The current means of doing overplotting is modal and confusing to 
> many used to IDL's approach. It is easy to forget what the current mode 
> is. IDL uses different commands (e.g., oplot vs plot) to overplot. Some 
> alternatives John and I mentioned:
> 
> a) generate 'o' versions of all plot functions (oplot, oimplot, etc.). 
> Easy to do but clutters the namespace.
> 
> b) have an 'over' function to apply to all such commands: over(plot, x, 
> y, color='g')
> 
> c) use a keyword argument to only apply to the function call:
> plot(x, y, hold=True) # doesn't change the hold state after completion, 
> but does overplot
> 
> I'm happy to have c) myself.

+1 for c), +0 for a) and -0 for b), I do not like the idea of having two
time the number of functions for this...if only because it will clutter
help(matplotlib.matlab) or dir(matplotlib.matlab) for example

> 5) For many customizations plot objects must be manipulated directly. 
> I'm wondering if this is a problem or not (I suspect that it is for a 
> reasonably large class of user). In particular I'm worried that the 
> leap to the object view is sufficiently high enough that many less
> sophisticated users will find that an off-putting hurdle. How does 
> matlab handle these sorts of customizations? The same way matplotlib 
> does? If so then I suppose my worries are unfounded. Keeping a lot of 
> the customization exposed within a purely functional interface means
> adding more functions or keywords which is its own problem. To be more 
> specific, how minor ticking is handled is a good example of making the 
> keyword interface richer and avoiding object manipulations for common 
> customizations:
> 
> plot(x, y, xminordiv=4)
> 
> vs
> 
> plot(x, y)
> ax = gca()
> ax.xaxis.set_major_locator(MultipleLocator(20))
> ax.xaxis.set_minor_locator(MultipleLocator(5))
> # update 
> The same could be said for specifying different kinds of tickers

many times matlab require to use an "object" approach with set/get for
advanced customization or for performance reason when doing dynamic
stuff...In general having to do the same in matplotlib is thus not a big
problem, provided that we have the "get" return all the settable
parameters, or that the python help work well for the same purpose. 
I think there has been new development that allow the get to work like
in matlab now, so this is great for me!

Avoiding object manipulation is a good idea for common stuff imho, like
for the proposed ticking control. In fact avoiding the object approach
for simple stuff is a strength of matlab I feel, because it allows for a
quick and dirty approach to plotting that is often enough, and then you
always have the possibility to dig into an object approach at any time
should you have the need for advanced customization/usages...
All of this for saying that the current approach suits me well, and that
I am +0/-0 on adding  non-object based alternative to replace something
that is feasable using object now. the +0/-0 is dependent on the
frequency, I am -0 doing this for something that is seldom used, but I
fear that "seldom" is dependent on applications/users, so it will not
always be easy to have everybody agree on what to add...

> 6) If one does these object manipulations the display is not updated. 
> One of John's list postings suggests resizing or calling the draw 
> method. The first is often unacceptable, and the second isn't quite so 
> obvious (since it requires specifying a renderer). Perhaps a simple 
> function to do the update that doesn't start a mainloop (as show does) 
> is needed. John responded:
> >
> > This is a problem.  I think the solution may be to override setattr in
> > the artist base class to call draw_if_interactive.  The matlab
> > interface could add this method at module load time so as to not break
> > the interface separation between the OO layer and the matlab layer.
> > I'll have to look into it.
> 
> (could it be as simple as defining update() to get the current renderer 
> and then call gcf().draw(currentrenderer)?)

I though that calling draw() would update the active figure without
starting the mainloop already, or am I confused? Alternatively, in the
fltk backend, I have allowed calling show() multiple times, it just
check before running the mainloop that it is not already running...Maybe
this is also feasible in a more general way?


Best regards,

Greg.