matplotlib-devel Mailing List for matplotlib

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:
 Abraham> Thanks for the tip on variable expansion. I'll add it in
 Abraham> to my current code.
Hi Abraham,
Just wanted to let you know I haven't dropped off the face of the
planet. With SciPy looming and other deadlines, I haven't had a
chance to look into your code in any detail. I'll be away all of next
week, so it will be some time until I get a chance to take a look.
Keep plugging away (pun intended) and hopefully we can put together
something nice in the near term. I think your hybrid solution of
using a plain text key/val pair format for rc, and user customizable
python for toolbar config, is a good one.
JDH

Abraham Schneider wrote:
> I completely agree. I recently changed the code to allow a path to be 
> specified (':' deliminated). I hadn't thought of allowing '$VAR' syntax 
> .. something to think about. However, if people have a .matplotlibrc 
> file in their home directory, it should make it so people aren't mucking 
> up things with the plugins.. I'll have to check the behavior of 
> find_module to see what it does with '~' and such.
You can expand the user-given string by doing:
user_dirlist = os.path.expanduser(os.path.expandvars(user_path)).split(':')
This gives you a list of directories to search, with user ~names and 
$VARIABLES expanded out. This approach worked fine for mayavi.
Best,
f

Abraham Schneider wrote:
> I do like the idea, and I was actually going to suggest something 
> similiar earlier on, but thought it wise at the time not to rock the 
> boat too much.. I am currently using this technique for my own code and 
> it's working out extremely well. The biggest problem with this approach, 
> is that I'm guessing the average user doesn't want to trawl through 
> python code to change a setting, or worry why Matplotlib doesn't work 
> because of some strange error message.
> 
> Because of this, I think it might make the most sense to partition the 
> rc file. For common settings, keep the current RC format, but then allow 
> python code to be executed for other settings.
> 
> A simple approach for this might be to add in directives to the RC 
> language like:
> 
> @import('file.rc')
> 
> or
> 
> @import('file.py')
> 
> Depending on the file type (i.e. ends in 'rc' or ends in 'py'), the file 
> could be parsed properly (either executed with 'execfile' with a given 
> namespace, or operate on rcParams).
-1, too complicated to code and maintain, IMHO. And @foo looks poised to 
become valid python syntax, in case you've missed the recent firestorms on 
c.l.py and python-dev.
In my view, matplotlib (and similarly ipython) are already tools for people 
coding in python to begin with. So they can deal with python syntax, 
otherwise they wouldn't be using them. Simplified syntaxes may make sense for 
configuring end-user programs, but for that we already have ConfigParser in 
the stdlib. We have better things to do than reinventing half-working 
implementations of toy languages, and users will always end up needing an if 
statement, a looping construct, a system access function, etc. Might as well 
just give them all of python and be done with it, I think.
The approach I have in mind for ipython is simply making sure that any 
exceptions generated during the execution of this file are presented very 
clearly to the user, with full source details and a clear message wrapping 
them going to stderr. This will indicate not only the exception but the fact 
that it is occurring in the user's config file and that ipython (or 
matplotlib) can't proceed further until this is fixed. IPython comes with a 
better exception formatter than the default (ultraTB, essentially a console 
port of cgitb); matplotlib is welcome to use it.
Best,
f

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
> Fernando> 2. From some of your syntax struggles, I'm starting to
> Fernando> wonder whether it would be best to turn the
> Fernando> .matplotlibrc file into a proper python one. I followed
> Fernando> the same approach with ipython of having a custom
> Fernando> syntax, and now I regret it. It appears easier
> Fernando> initially, but in the long term it's clunky (at least
> Fernando> for ipython). For ipython's next major revision, I plan
> Fernando> on dumping its own rc format and allowing users to
> Fernando> define their configuration using plain python syntax.
> Fernando> Just some thoughts.
> 
> I had the same thought this morning - you start with a simple config
> file, key/value pairs, but as you add features you find yourself
> writing a little primitive mini-language. Why ham-string yourself,
> when you already have an elegant, simple, powerful language available
> - python!
There are a few technical issues with this problem, some of which I've partly 
thought about. This will be one of my first things to do once I'm done with 
matplotlib support in ipython, as part of the rewrite. Perhaps we could share 
some of the work for this problem with a light module for handling python 
config files with proper namespace control and recursive inclusion (important 
for handling global defaults modified by local project fine-tuning).
Best,
f

Fernando Perez wrote:
>
>
> 1. I think plugin support is a fantastic idea, but I hope it can be 
> made user-extensible in local paths. I recently modified mayavi 
> (available in current CVS) precisely in this manner, and I think it's 
> a very useful thing. In lab settings where users are not allowed to 
> write to system directories, it becomes very important that they can 
> add their own plugins in local paths. This also allows you to keep 
> your personal extensions alive as matplotlib versions are upgraded, 
> since your directories are untouched.
>
> What I did for mayavi was to add a search-path option to mayavi, made 
> of colon-separated dirs with ~user/$VAR support. Any such dir gets 
> added to mayavi's search path for user-defined filters and modules 
> (the equivalent of plugins), and you can load a user module just like 
> you can load a builtin:
>
> load_module('Glyphs') -> loads mayavi's Glyphs module
> load_module('User.Glyphs') -> loads a user-defined Glyphs module from 
> the search path.
>
> I think it's important that it's a _path_ and not a single directory, 
> because this allows a research group to maintain shared extensions 
> suited for their purposes, and individual users to add personal 
> modifications which don't fit group projects.
I completely agree. I recently changed the code to allow a path to be 
specified (':' deliminated). I hadn't thought of allowing '$VAR' syntax 
.. something to think about. However, if people have a .matplotlibrc 
file in their home directory, it should make it so people aren't mucking 
up things with the plugins.. I'll have to check the behavior of 
find_module to see what it does with '~' and such.
I like the idea of 'load_module'. Currently all the plugins in the 
directories are loaded automatically. There is a certain nicety, though, 
to automatically having it load all the plugins found in a particular 
directory. Less cumbersome for most users.
Abe

I do like the idea, and I was actually going to suggest something 
similiar earlier on, but thought it wise at the time not to rock the 
boat too much.. I am currently using this technique for my own code and 
it's working out extremely well. The biggest problem with this approach, 
is that I'm guessing the average user doesn't want to trawl through 
python code to change a setting, or worry why Matplotlib doesn't work 
because of some strange error message.
Because of this, I think it might make the most sense to partition the 
rc file. For common settings, keep the current RC format, but then allow 
python code to be executed for other settings.
A simple approach for this might be to add in directives to the RC 
language like:
@import('file.rc')
or
@import('file.py')
Depending on the file type (i.e. ends in 'rc' or ends in 'py'), the file 
could be parsed properly (either executed with 'execfile' with a given 
namespace, or operate on rcParams).
This could also support other features such as verbosity:
@verbose moderate
That said, I think the current syntax for adding widgets and connecting 
them isn't too bad. I think it's worth experimenting with to see which 
is easier to use.
Abe
John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
>>>>>> 
>>>>>>
>
> Fernando> 2. From some of your syntax struggles, I'm starting to
> Fernando> wonder whether it would be best to turn the
> Fernando> .matplotlibrc file into a proper python one. I followed
> Fernando> the same approach with ipython of having a custom
> Fernando> syntax, and now I regret it. It appears easier
> Fernando> initially, but in the long term it's clunky (at least
> Fernando> for ipython). For ipython's next major revision, I plan
> Fernando> on dumping its own rc format and allowing users to
> Fernando> define their configuration using plain python syntax.
> Fernando> Just some thoughts.
>
>I had the same thought this morning - you start with a simple config
>file, key/value pairs, but as you add features you find yourself
>writing a little primitive mini-language. Why ham-string yourself,
>when you already have an elegant, simple, powerful language available
>- python!
>
>When I get some more time tomorrow I'll take a close look at Abraham's
>code, and whether it might make more sense to move this section, or
>the who rc file, into python. That Abraham was able to factor out /
>modularize most of the toolbar code will certainly pave the way.
>
>Abraham, had you given this approach any thought in the midst of your
>work?
>
>Thanks!
>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
> 
>

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> 2. From some of your syntax struggles, I'm starting to
 Fernando> wonder whether it would be best to turn the
 Fernando> .matplotlibrc file into a proper python one. I followed
 Fernando> the same approach with ipython of having a custom
 Fernando> syntax, and now I regret it. It appears easier
 Fernando> initially, but in the long term it's clunky (at least
 Fernando> for ipython). For ipython's next major revision, I plan
 Fernando> on dumping its own rc format and allowing users to
 Fernando> define their configuration using plain python syntax.
 Fernando> Just some thoughts.
I had the same thought this morning - you start with a simple config
file, key/value pairs, but as you add features you find yourself
writing a little primitive mini-language. Why ham-string yourself,
when you already have an elegant, simple, powerful language available
- python!
When I get some more time tomorrow I'll take a close look at Abraham's
code, and whether it might make more sense to move this section, or
the who rc file, into python. That Abraham was able to factor out /
modularize most of the toolbar code will certainly pave the way.
Abraham, had you given this approach any thought in the midst of your
work?
Thanks!
JDH

Abraham Schneider wrote:
> Okay, I think I've gotten all the major bugs out, and the code can be 
> upgraded from 'major hack' to 'minor hack'. The files that were changed 
> (as well as a directory patch) can be found at:
> 
> http://www.cns.nyu.edu/~abes/matplotlib/
[...]
I've stayed off this discussion because I'm a bit swamped, but I'd like to 
make a couple of quick comments.
1. I think plugin support is a fantastic idea, but I hope it can be made 
user-extensible in local paths. I recently modified mayavi (available in 
current CVS) precisely in this manner, and I think it's a very useful thing. 
In lab settings where users are not allowed to write to system directories, it 
becomes very important that they can add their own plugins in local paths. 
This also allows you to keep your personal extensions alive as matplotlib 
versions are upgraded, since your directories are untouched.
What I did for mayavi was to add a search-path option to mayavi, made of 
colon-separated dirs with ~user/$VAR support. Any such dir gets added to 
mayavi's search path for user-defined filters and modules (the equivalent of 
plugins), and you can load a user module just like you can load a builtin:
load_module('Glyphs') -> loads mayavi's Glyphs module
load_module('User.Glyphs') -> loads a user-defined Glyphs module from the 
search path.
I think it's important that it's a _path_ and not a single directory, because 
this allows a research group to maintain shared extensions suited for their 
purposes, and individual users to add personal modifications which don't fit 
group projects.
2. From some of your syntax struggles, I'm starting to wonder whether it would 
be best to turn the .matplotlibrc file into a proper python one. I followed 
the same approach with ipython of having a custom syntax, and now I regret it. 
 It appears easier initially, but in the long term it's clunky (at least for 
ipython). For ipython's next major revision, I plan on dumping its own rc 
format and allowing users to define their configuration using plain python 
syntax. Just some thoughts.
Anyway, I htink this is great for matplotlib, and I hope you can bring it to a 
good conclusion. Great work!
Best,
f

Okay, I think I've gotten all the major bugs out, and the code can be 
upgraded from 'major hack' to 'minor hack'. The files that were changed 
(as well as a directory patch) can be found at:
http://www.cns.nyu.edu/~abes/matplotlib/
This code currently only works/tested with GTK and with the pygtk2.2 
section (although the 2.4 section is trivial to update). All the major 
changes were to the backend_bases.py file, so it should also be trivial 
to port it to the other backends as well (i.e. basically just a copy and 
paste).
All toolbar functionality is now handled in the plugin file 'toolbar.py' 
file using various children of 'toolbar_widget'. I had to change the 
syntax in the .matplotlibrc file somewhat to allow variable arguments to 
the widgets (e.g. the 'view_controller' doesn't need tooltips, or text, 
as it isn't visible) to:
toolbar.widget: <toolbar, home_button>: home, Home, Reset original view
where in, '<toolbar, home_button>:', toolbar is the module name, and 
home_button is the class. The rest are arguments (name, text, and 
tooltip in this case). There is a small issue with the fact that commas 
cannot be included in the tooltips.
I also fixed the plugins.py code so that it will now search multiple 
plugin paths, deliminated by ':'.
The files 'toolbar.py' and 'print.py' have to go into the plugins 
directory for this to work, and the other python files into their normal 
locations.
Except for changing the cursors (I didn't get around to writing that 
code), it appears to work exactly the same as the old version (helped 
tremendously of course by using mostly the same code).
Abe

Thanks.
I have moved most of the toolbar code over to a plugin file, and it 
seems to work (except for a couple of quirks which I'm working out, and 
once I do I'll send the code).
The signal/slot method seems to work well for the zoom and pan buttons. 
Each one is connected to the other's 'disable' function, which does an 
mpl_disconnect(...). Most of the work was copying the original code in 
the toolbar into separate classes, and getting them work properly (there 
were a couple places where I had to change things around)
As for the home, back, and forward button, I tried the observer pattern, 
as you suggested, and it seems to work well. I added a property to the 
widgets called 'visible', which if set to false, doesn't actually get 
added to the toolbar, but does still get loaded into memory, and capable 
of participating in signal handling.
I then made a class called 'view_controller', which keeps a Stack of the 
current views (I did need to modify the toolbar to access and set the 
views ('get_current_view', and 'set_view'). Whenever a control wants to 
save the view, it can emit the signal 'new_view', with the current view 
as the parameter. Likewise, the view-related buttons are connected to 
the view_controller such that they can set the current view (via 
'toolbar.set_view').
I should have the code ready either later tonight, or sometime tomorrow.
As for putting the plugin code back in __init__.py, I seem to remember 
when I originally did this I came across dependency problems when 
dealing the the toolbar. 'backends.py' currently imports the plugins, so 
it is transparent to the user once again.
A verbose mode on the rc file sounds like an incredibly good idea.
Abe
John Hunter wrote:
>>>>>>"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
>
>
>-------------------------------------------------------
>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
> 
>

>>>>> "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

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:
 Abraham> Hi. I realized that having plugins loaded from the
 Abraham> __init__.py file could cause dependency problems,
 Abraham> depending on what was being done in the plugin. So I
 Abraham> moved the code to a separate file called 'plugins.py'
 Abraham> (attached). This also allows you to decide whether you
 Abraham> want to load the plugins in the first place. It's also a
 Abraham> cleaner solution in general..
 Abraham> It's pretty rough code hacked together during wait
 Abraham> time. I also wrote a quick 'print button' plugin (also
 Abraham> attached) for proof of concept. The plugin only works
 Abraham> with GTK right now, but it checks the backend being used,
 Abraham> so it should be fairly simple to hack the other
 Abraham> GUI/platform backends to use it.
 Abraham> I'm interested in what people think.. Even if it doesn't
 Abraham> get included in the main source, it's easy enough to add
 Abraham> in, that upgrades will no longer be a problem.
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

Great, this is doing the job nicely, thanks ! I am not very clear as to=20
what the 'subs' argument really does. In your example:
 > #full control
 > gca().set_xscale('log',base=3D100,subs=3D[10,20,50])
 > #Major tick every 16**i, minor tick every subs*16**i
(16 should be 100 right?). There's a major tick at 100, 100^2, 100^3,=20
etc. And you're saying there are minor tick marks at 10*100*i ?!?
What if you'd want tick labels [0, 1, 2, 3, 4, ...] instead of (in base=20
2, say) [1, 2, 4, 8, 16, ...] ? Is that easily done? I tried to obtain=20
it based on the example custom_ticker1.py (in the examples=20
subdirectory), but haven't been successful so far.
Thanks A LOT for the update of axes.py and ticker.py,
Dominique
Gregory Lielens wrote:
> 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 betwee=
n
> 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)
>=20
> #compatible with previous usage
> gca().set_xscale('log')=20
> # major tick every 10**i, minor tick every range(2,10)*10**I
>=20
> #change base
> gca().set_xscale('log',base=3D16)
> #Major tick every 16**i, minor tick every range(2,16)*16**i=20
>=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
>=20
>=20
> This gives me all the flexibility I need, and I feel it is a step in th=
e
> right direction, but:
> -maybe a rework of log ticker is needed so that it use minor/major tic=
k
> 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 sub=
s
> 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 nic=
e
> framework to have fully automatic and nicely configurable log ticking
> :-)=20
>=20
>=20
> Best regards,
>=20
> Greg.
>=20
> PS: the 2 modified files are included, I made my modif relative to
> CVS...
>=20
>=20
>>-----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?
>>
>>
>>Hi,
>>
>>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.
>>
>>Thanks,
>>Dominique

Oups, sorry, sent an older version of my modified files...
Here they are...
Also, this works of course for both x and y scales, who can have
different bases and subs...
Best regards, Greg.

Hi. I realized that having plugins loaded from the __init__.py file 
could cause dependency problems, depending on what was being done in the 
plugin. So I moved the code to a separate file called 'plugins.py' 
(attached). This also allows you to decide whether you want to load the 
plugins in the first place. It's also a cleaner solution in general..
It's pretty rough code hacked together during wait time. I also wrote a 
quick 'print button' plugin (also attached) for proof of concept. The 
plugin only works with GTK right now, but it checks the backend being 
used, so it should be fairly simple to hack the other GUI/platform 
backends to use it.
I'm interested in what people think.. Even if it doesn't get included in 
the main source, it's easy enough to add in, that upgrades will no 
longer be a problem.
Abe

> We removed the typecode= kwargs when porting matplotlib to be
> compatible with Numeric and numarray. It's my understanding that the
> kwarg version works with all (reasonable recent) versions of Numeric
> but only very recent versions of numarray. What version of
> Numeric/numarray are you using?
I'm using the Enthought distribution 2.3.3 which is supposed to come 
with Numeric 23.1 but seems to provide Numeric 23.3 indeed!
JM. Philippe

>>>>> "Jean-Michel" == Jean-Michel Philippe <jea...@ir...> writes:
 Jean-Michel> Hello, I installed matplotlib 0.61 today and had a
 Jean-Michel> bug in the function detrend_linear
 Jean-Michel> (matplotlib/mlab.py line 113):
 Jean-Michel> xx = arange(len(x), x.typecode())
 Jean-Michel> should certainly be replaced with:
 Jean-Michel> xx = arange(len(x), typecode=x.typecode())
 Jean-Michel> It works well on my computer!
We removed the typecode= kwargs when porting matplotlib to be
compatible with Numeric and numarray. It's my understanding that the
kwarg version works with all (reasonable recent) versions of Numeric
but only very recent versions of numarray. What version of
Numeric/numarray are you using?
Todd, where would we expect 
 xx = arange(len(x), x.typecode())
to fail and is there a good workaround?
Thanks for the report,
JDH

Hello,
I installed matplotlib 0.61 today and had a bug in the function 
detrend_linear (matplotlib/mlab.py line 113):
 xx = arange(len(x), x.typecode())
should certainly be replaced with:
 xx = arange(len(x), typecode=x.typecode())
It works well on my computer!
Regards.
JM. Philippe

Abraham Schneider wrote:
> What might be a cool extension on this idea, would be the ability to 
> specify 'plugin' actions to add to the toolbar:
> 
> toolbar.buttons : (name, tooltip, image, function), (name, tooltip, 
> image, function)
> 
> The difficulty would specifying which modules to load. One simple 
> approach might be to have a directory called 'plugins', in which all 
> modules automatically get loaded.
+1
Note that this should be specifyable as a colon-separated search path where 
matplotlib can look for all available plugins. This allows users to extend 
their local installation with custom things which survive across system-wide 
upgrades.
I recently patched MayaVi to do exactly this with Filters and Modules (it's in 
the mayavi CVS already), and it's extremely useful.
In mayavi, any directory in the mayavi search path is scanned for a subdir 
called Filters/ and one called Modules/. Any .py file found there is added to 
the User submenu of Mayavi's main Filters and Modules menus. With this 
system, local user extensions become automatically available to the GUI. In 
scripts, they can be loaded with a prepended 'User.' string:
load_module('Glyphs') -> loads MayaVi's Glyphs module
load_module('User.Glyphs') -> loads a users's customized Glyphs module, 
without clashing with the system-wide one.
I think this approach is very useful, esp. because it allows research groups 
to have directories of common functionality useful to their projects, and 
individual users can still add their own particular Filters/Modules.
Best,
f

What might be a cool extension on this idea, would be the ability to 
specify 'plugin' actions to add to the toolbar:
toolbar.buttons : (name, tooltip, image, function), (name, tooltip, 
image, function)
The difficulty would specifying which modules to load. One simple 
approach might be to have a directory called 'plugins', in which all 
modules automatically get loaded.
I think this would take about the same amount of code as hard-coding a 
single printer option in, and might allow more flexibility (easier to 
add/remove buttons, and easier to change what action they perform).
I wrote a quick patch (attached to the email) which allows for two new 
rc params:
plugins.directory : <directory>
 any file in this directory ending in '.py' is automatically imported
toolbars.buttons: (name, tooltip, image, function), ...
 a list of the tuples is created
I didn't edit any of the backend code yet, but it should be trivial (at 
least in the case of the gtk backend) to convert 'toolitems' to an 
array, and then "if matplotlib.rcParams['toolbar.buttons']: 
toolitems.extend(matplotlib.rcParams['toolbar.buttons'])"
Abe
John Hunter wrote:
>>>>>>"Steve" == Steve Chaplin <ste...@ya...> writes:
>>>>>> 
>>>>>>
>
> Steve> Perhaps the .matplotlibrc file could have lines like
> Steve> printcommand: None printcommand: '"lpr %s" % path' And if
> Steve> printcommand is not None an extra toolbar button is created
> Steve> which calls os.system(printcommand) to print the file.
>
>This is a good idea, perhaps the rc param should be
>savefig.printcommand. There was a post on the users list which
>contained some help on how to print from wx on win32.
>
>Anyone want to take the lead here?
>
>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
> 
>

Paul Barrett wrote:
> OK, I've created a patch to work around the 'gv' problem for dense line plots. 
> Attached is a PS file created from this patch. Please test to see if it solves 
> your problem. If it does, I'll commit the patch to CVS. It worked for me on 'ggv'.
Works OK now with gv on Fedora Core 2.
Thanks,
f

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> Perhaps the .matplotlibrc file could have lines like
 Steve> printcommand: None printcommand: '"lpr %s" % path' And if
 Steve> printcommand is not None an extra toolbar button is created
 Steve> which calls os.system(printcommand) to print the file.
This is a good idea, perhaps the rc param should be
savefig.printcommand. There was a post on the users list which
contained some help on how to print from wx on win32.
Anyone want to take the lead here?
JDH