matplotlib-devel Mailing List for matplotlib

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:
 Abraham> All the code (hopefully, let me know if it's not
 Abraham> working/I left something out) can be found:
 Abraham> http://www.cns.nyu.edu/~abes/matplotlib/
Hi Abraham,
It looks promising - nice job!
In my post yesterday I thought it would be nice to do all the toolbar
buttons this way (eg all the defaults on the nav toolbar). Now I am
on the fence. Not only because they already work, but because some of
them are tightly coupled. Eg, home, back and forward all operate on
the same view limits stack, and thus make sense together as an entity.
So a totally modular design may not make sense for all the buttons.
However, it may nonetheless be worth investigating whether the whole
toolbar could/should be built with this kind of mechanism, in part
because it would be cool/useful and in part because it would help
expose the issues we need to handle like coordination between various
buttons, sharing data, etc. Also, if we want to implement something
like the mechanism which supports signals (good idea by the way!) we
will need to make some changes to the existing buttons so the user
can, for example, disconnect them (eg call something like do_toggle on
the pan/zoom button). I wonder if the best approach here is simply to
use an observer pattern and have all buttons disconnect their signals
when another button is clicked. 
Are you interested in exploring this Abraham? Or would you rather
simply see extensions to the existing toolbar and leave the current
implementation mostly untouched. I think the cleanest and most
powerful design would be a single framework in which all the buttons
could be handled in a single configurable way, but this may be too
much to bite off. What do other people think?
If we do try to fit everything in one roof, we would need some way to
call code implemented by the respective backend toolbars. Currently,
the only truly backend dependent toolbar action is savefig, in which
the various backends launch the file save dialog. But this could be
handled by using a magic name for the module which the backend could
detect and call when clicked, eg, self.savefig in that special case.
One minor implementation note: I thought it made more sense to put all
your code that was in plugins.py in __init__.py so everything was
loaded by default at init time. We could couple this with an rc param
plugins.on : True # or False
so the user could disable plugins. Then the last line of the rc file
would be
if rcParams['plugins.on']: load_plugins()
On a related note: I think now might be a good time to introduce a
verbose setting in rc. The more magic that happens under the hood
(loading various rc files, loading plugins) the more it would be nice
to get some feedback, particularly when debugging. Something like
silent | minimal | moderate | screaming. Make minimal the default,
and at the minimal level report things like loading rc file from such
and such, loading plugin module from such and such a dir. At the
moderate level we would report font loads and other such events, and
screaming report .... well you know.
Thanks!
JDH

I hadn't put much thought about passing rcParams as a parameter, as 
load_plugins wasn't supposed to be called manually, but rather called 
automatically when importing 'matplotlib.plugins'.
The code I had sent previously was more proof of concept of what could 
be done with the plugin system. I like your ideas of how to add buttons 
to the toolbar, so I implemented it last night. Now in the .matplotlibrc 
file you can do:
toolbar.widget : print, print, prints figure, mprint, print_button
toolbar.connect : print.clicked -> nothing.do_toggle
toolbar.widget : nothing, nothing, does nothing, mprint, nothing_button
There are several things happening here:
(1) I had to alter __init__.py some, so that rcparams acted more like 
opt.parse. The default behavior is the exact same as usual, except that 
there is an addition. Normally for an entry you have:
[None, validate_x]
There is now an extra optional field, which defaults to 'store', but can 
also take on the value of 'append':
[None, validate_x, 'append']
Thus, several entries of 'toolbar.widget', will add append each entry to 
a big list.
(2) The fields of 'toolbar.widget' are:
<name>, <text>, <tooltip>, <module>, <class>
The name is needed for the toolbar.connect, which I will get to shortly. 
The text and tooltip, are the same as before. The module is required, as 
although it is loaded as plugin, the toolbar code that creates widgets 
from these, still needs to import something. The class is a child class 
of 'toolbar_widget'.
(3) The reason for creating a 'toolbar_widget' class, is to handle the 
complexity of signalling between buttons that you mention. Basically it 
is your generic signal/slot design, where one widget's signal can be 
connected to another widget's slot. Thus the line:
toolbar.connect: print.clicked -> nothing.do_toggle
This uses the named widget (<name>) to connect it's signal (clicked) to 
the other widget's slot (do_toggle).
While currently the code only supports buttons, I thought it might be 
wise to allow other widget types. The backends can figure out what to 
render on the class type.
(4) backend_bases.py: added a 'widgets' dict, that is loaded with 
_init_toolbar from the rcParams files. The connections are then iterated 
through, so the newly loaded widgets are all connected correctly.
(5) backend_gtk: changed to work with the new backend_bases.py widget .. 
basically just iterates through 'self.widgets', and adds them to the toolbar
All the code (hopefully, let me know if it's not working/I left 
something out) can be found:
http://www.cns.nyu.edu/~abes/matplotlib/
I included a patch in the file for all the changes to the code, which 
should hopefully work. As well, the new files created, and changed files 
are also in the directory:
* mprint.py: gets placed in your plugin directory, and defines the 
print_button, and nothing_button.
* plugins.py: the plugin code
* toolbar_widget.py: defines the toolbar_widget's, which are used in mprint
The code is still pretty rough, and small things like allowing for more 
than one plugin directory hasn't yet been addressed (or going through 
them recursively).
As far as changing the configuration midsession, the toolbar would have 
to be reinitialized.
Abe
>
>I tried out your code and have a few questions.
>
>Your example only works on the current figure toolbar - it this
>desirable, or would it be better to modify the default toolbar? Also,
>how do you use it? After your figure is realized, do you call
>
> >>> load_plugins(rcParams)
>
>to get your buttons? That seems like it would be cumbersome to have
>to do this with every figure....
>
>And why does load_plugins take rcParams as an arg rather than work on
>the rcParams default? Do you plan on keeping different params with a
>different plugins directories?
>
>I may not be understanding how your code is supposed to work, but I
>was envisioning something a little different after reading your
>original post. I thought something along the lines of the following
>in rc
>
># format is Name, Tooltip, image basename, callback
>plugins.dirs : /path/to/plugins1:/path/to/plugins2
>toolbar.button : Home, Reset original view, home_icon, mybackend.home
>toolbar.button : Back, Back to previous view, back_icon, mybackend.back
>toolbar.button : Forward, Forward to next view, forward_icon, mybackend.forward
>toolbar.button : Pan, Pan axes with left mouse, zoom with right, move_icon, mybackend.pan
>toolbar.button : Zoom, Zoom to rectangle, zoom_to_rect, mybackend.zoom
>toolbar.button : Print, Print to PS, print_icon, plugins.print_ps
>
>
>The order of the toolbar.button calls would determine which buttons
>were placed in the toolbar and in what order. mybackend would be a
>special string that matplotlib would use to substitute in for the
>current backend, and each backend would implement these functions.
>
>plugins (in the example plugins.print_ps) is a python code dir
>somewhere in the plugins.dirs search path. Thus the same code could
>be used to both build the default toolbar and used to customize it
>(remove buttons, change their order, add user buttons). 
>
>I used icon names without extensions above because the different
>backends generally need icons of different types, and the backend
>could be responsible for supplying the extension. GTK could also
>detect special names like STOCK_PRINT and handle those.
>
>One thing this setup doesn't provide for is the ability to easily
>switch to different configurations in the middle of an interactive
>session. Is this important?
>
>Another design issue that comes to mind is how to handle communication
>between buttons. In the current toolbar2 design, when the zoom to
>rectangle button is pressed, the pan/zoom callbacks are disconnected
>and vis-a-versa. Presumably a more sophisticated model would have to
>be used to handle the connection and disconnection of multiple buttons
>that want to listen in on press/motion events. 
>
>It would provide a nice framework for supporting user contributions,
>eg measurement tools, other navigation tools, etc...
>
>JDH
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
>100pk Sonic DVD-R 4x for only 29ドル -100pk Sonic DVD+R for only 33ドル
>Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
>

On Wed, 2004年08月18日 at 21:45, Dominique Orban wrote:
> Great, this is doing the job nicely, thanks ! I am not very clear as to 
> what the 'subs' argument really does. In your example:
> 
> > #full control
> > gca().set_xscale('log',base=100,subs=[10,20,50])
> > #Major tick every 16**i, minor tick every subs*16**i
> 
> (16 should be 100 right?).
oooouuuups, yes indeed, sorry!
> There's a major tick at 100, 100^2, 100^3, 
> etc. And you're saying there are minor tick marks at 10*100*i ?!?
hum, not really, minor tick every array([10,20,50])*100**i (I use array
else python (and maybe some reader too familiar with python lists) may
think I mean [10,20,50] concatenated 100**i with itself...that could be
a very long list indeed ;-) )...
So minor ticks at
...0.001,0.002,0.005,0.1,0.2,0.5,10,20,50,1000,2000,5000,...
> What if you'd want tick labels [0, 1, 2, 3, 4, ...] instead of (in base 
> 2, say) [1, 2, 4, 8, 16, ...] ? 
> Is that easily done? I tried to obtain 
> it based on the example custom_ticker1.py (in the examples 
> subdirectory), but haven't been successful so far.
You mean tick labels like a linear plot, but with log ticking? (and
beware of 0, I doubt you will be able to see the 0 label in a log plot
except if you do a *LOT* of paning ;-) ;-P )
If yes, this is not yet possible, because only "major" ticks (the one
corresponding to base**i) are labeled, and what you want is labeling of
all ticks...this would be feasible when I cleanup minor/major ticking
for logscale, in the meantime I added a flag to logformatter to tell
"label all ticks" instead of "label only major ticks".
Then, to do what you want (or what I believe you want ;-) ),
simply do 
gca().set_xscale('log',base=1000,label_minor=True).
the base should be large enough so that your whole xrange is in it, and
by default minor tick will be generated every unit.
Be aware though that due to log spacing, last labels could be very close
to each other and this ain't pretty ;-) That's why I allowed full
control on minor ticks with subs, often you do want to carefully choose
which ticks you want, because you can end up with a black mes of ticks
and labels on the right of your graph if you don't...
> Thanks A LOT for the update of axes.py and ticker.py,
you're welcome,
Greg.

Hi, I though about this too and your message has convinced me it was
worth spending a few minutes adding this ;-)
I just patched loglocator and logformater to be able to use arbitrary
base, and also to use arbitrary "minor" ticks. Well, I put minor between
quotes because Logticker do not really use minor ticks, only discard
label for ticks that are not integer exponents of base...
Usage is like this:
Semilogx(x,y)
#compatible with previous usage
gca().set_xscale('log')=20
# major tick every 10**i, minor tick every range(2,10)*10**I
#change base
gca().set_xscale('log',base=3D16)
#Major tick every 16**i, minor tick every range(2,16)*16**i=20
#full control
gca().set_xscale('log',base=3D100,subs=3D[10,20,50])
#Major tick every 16**i, minor tick every subs*16**i=20
This gives me all the flexibility I need, and I feel it is a step in the
right direction, but:
 -maybe a rework of log ticker is needed so that it use minor/major tick
mechanism? Current mechanism is not as clean as it could, imho
 -maybe autoscale for loglocator should adjust the base/range to avoid
excessive ticking (A discussion I had with john, with a zoom out it is
possible to have very dense ticking)...Not so easy to do though, as subs
has to be adjusted too if one does not want too many minor ticks, as
this adjustment is not so easy to do if one want "usefull" minor ticks
in logscale...
I thing these 2 points are linked, I would not go to 2 if 1 is not done,
but if one is done (using some kind of linear locator (with autoscale
capability) on 1 decade for minor ticks, and repeat this minor tick on
each decade as I have done with my subs, I think we can have a very nice
framework to have fully automatic and nicely configurable log ticking
:-)=20
Best regards,
Greg.
PS: the 2 modified files are included, I made my modif relative to
CVS...
> -----Message d'origine-----
> De : mat...@li...=20
> [mailto:mat...@li...] De la=20
> part de Dominique Orban
> Envoy=E9 : mardi 17 ao=FBt 2004 18:57
> =C0 : mat...@li...
> Objet : [Matplotlib-users] Log plot in base b?
>=20
>=20
> Hi,
>=20
> What would be the easiest way, in matplotlib, to achieve log scaling,=20
> along the x axis, say, in a base other than 10? I see in axes.py that=20
> semilog[xy] have LOG10 hardwired. I am using matplotlib 0.60.2.
>=20
> Thanks,
> Dominique
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on=20
> Blank Media 100pk Sonic DVD-R 4x for only 29ドル -100pk Sonic=20
> DVD+R for only 33ドル Save 50% off Retail on Ink & Toner - Free=20
> Shipping and Free Gift.=20
> http://www.shop4tech.com/z/Inkjet_Cartridge> s/9_108_r285
>=20
> _______________________________________________
>=20
> Matplotlib-users mailing list Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>=20