From: Perry G. <pe...@st...> - 2004-11-30 22:06:15
|
Yesterday I brought up some user interface issues with John. He agreed that these generally ought to be discussed in a broader forum (meaning he wasn't dead set against them; at least not most of them). So here were some of the thoughts that I raised that pertain mainly to generating plots during interactive analysis sessions: 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? 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']) 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. 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. 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 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)?) It's possible that there are two or more different kinds of functional interfaces and philosophy such that there should be different modules to satisfy the different camps. But both John and I thought that if at all possible, these sorts of issues should be accommodated within one module. That the matlab (soon to be pylab) shouldn't necessarily be a strict matlab clone in interface but also take some of the better ideas from other packages. Any comments on the above suggestions? Perry Greenfield |
From: Gregory L. <gre...@ff...> - 2004-12-01 11:05:46
|
> 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. |
From: John H. <jdh...@ac...> - 2004-12-01 21:26:46
|
>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes: Gregory> I though that calling draw() would update the active Gregory> figure without starting the mainloop already, or am I Gregory> confused? Alternatively, in the fltk backend, I have Gregory> allowed calling show() multiple times, it just check Gregory> before running the mainloop that it is not already Gregory> running...Maybe this is also feasible in a more general Gregory> way? The matlab interface draw function does not need the renderer passed as an arg (the FigureCanvas.draw method does) and it is intended for interactive use when you want to force a redraw >>> o = title('blah') >>> o.set_fontsize(12) # no draw >>> o.set_fontstyle('italic') # no draw >>> draw() # draw Perry and I discussed trying to come up with some python magic such that calls to setattr on an artist would trigger a call to the matlab interface draw_if_interactive. This would have to be done carefully, because some users will explicitly not want to force a redraw on any call to a setter since drawing is potentially an expensive operation. True, they could temporarily turn interaction off, but I think any solution here would need to be optional. JDH |
From: Alan G I. <ai...@am...> - 2004-12-01 15:30:29
|
On Tue, 30 Nov 2004, Perry Greenfield apparently wrote: > 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 The basic idea is very useful, but I think it is more common to specify the number of subdivisions rather than the number of tic marks. (E.g., 'freq' in gnuplot or 'minordiv' in GAUSS.) Maybe that's what you meant? I do not know the Matlab convention. fwiw, Alan Isaac |
From: Perry G. <pe...@st...> - 2004-12-01 15:48:46
|
On Dec 1, 2004, at 10:07 AM, Alan G Isaac wrote: > On Tue, 30 Nov 2004, Perry Greenfield apparently wrote: >> 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 > > The basic idea is very useful, but I think it is more common > to specify the number of subdivisions rather than the number > of tic marks. (E.g., 'freq' in gnuplot or 'minordiv' in > GAUSS.) Maybe that's what you meant? I do not know the > Matlab convention. > Yes, you are right, I meant number of subdivisions. |
From: Stephen W. <ste...@cs...> - 2004-12-02 00:35:06
|
On Tue, 2004-11-30 at 17:06 -0500, Perry Greenfield wrote: > Yesterday I brought up some user interface issues with John. A minor point: it would be nice if in toolbar2 the currently active zoom or pan tool was highlighted in some way. --=20 Stephen Walton, Professor, Dept. of Physics & Astronomy, Cal State Northrid= ge ste...@cs... |
From: Darren D. <dd...@co...> - 2004-12-02 03:50:41
|
On Wednesday 01 December 2004 07:34 pm, Stephen Walton wrote: > On Tue, 2004-11-30 at 17:06 -0500, Perry Greenfield wrote: > > Yesterday I brought up some user interface issues with John. > > A minor point: it would be nice if in toolbar2 the currently active > zoom or pan tool was highlighted in some way. Also a minor point on toolbar2, I have a suggestion for the zoom tool. If one wanted to zoom in on the a region near the corner or edge of a plot, I think it would be helpful if the zoom tool would remember the lower limits of the axis where the pointer exits the axis. The way it works now, you have to be sure to have the pointer on that last pixel inside the axis boundary when you release the mouse button. -- Darren |
From: Gregory L. <gre...@ff...> - 2004-12-02 09:48:28
|
On Thu, 2004-12-02 at 04:49, Darren Dale wrote: > On Wednesday 01 December 2004 07:34 pm, Stephen Walton wrote: > > On Tue, 2004-11-30 at 17:06 -0500, Perry Greenfield wrote: > > > Yesterday I brought up some user interface issues with John. > > > > A minor point: it would be nice if in toolbar2 the currently active > > zoom or pan tool was highlighted in some way. depending on the backend, it already is...(see fltk for example). I think it is not too difficult to add this for other backends...but only the other backends developers can tell :-) It is also available in the message area (nothing, or "pan/zoom mode", or "zoom to rect mode" is written before the cursor coordinates). > Also a minor point on toolbar2, I have a suggestion for the zoom tool. If one > wanted to zoom in on the a region near the corner or edge of a plot, I think > it would be helpful if the zoom tool would remember the lower limits of the > axis where the pointer exits the axis. The way it works now, you have to be > sure to have the pointer on that last pixel inside the axis boundary when you > release the mouse button. Good point, the behavior was intentional (as a way to cancel a zoom when you started it and though afterward is was not such a good idea), but I have also found this to be more annoying than useful, and anyway the back button is already there ready to help you cancel any action... I will have a look at this to change the behavior (it should check the coordinates of the zoom rect, and adjust it to clip to current axes limits) |