matplotlib-devel Mailing List for matplotlib (Page 540)

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

John Hunter wrote:
>>>>>>"Paul" == Paul Barrett <ba...@st...> writes:
> 
> 
> Paul> OK, I've created a patch to work around the 'gv' problem for
> Paul> dense line plots. Attached is a PS file created from this
> Paul> patch. Please test to see if it solves your problem. If it
> Paul> does, I'll commit the patch to CVS. It worked for me on
> Paul> 'ggv'.
> 
> Works for me (also ggv) - what did you do, break up paths longer than
> a certain size into multiple paths? I need to do the same for agg to
> fix Jin-chung's bug.
Yes. Paths are divided into mutiple paths of 1000 points (except for the last 
path with can contain upto 1001 points to prevent the last point from being 
orphaned). This path size seemed like a reasonable number. I didn't do any 
tests to determine the optimum path size. From the way gv behaves on my Linux 
box, it appears that 5000 points may be the limit.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:
 Paul> OK, I've created a patch to work around the 'gv' problem for
 Paul> dense line plots. Attached is a PS file created from this
 Paul> patch. Please test to see if it solves your problem. If it
 Paul> does, I'll commit the patch to CVS. It worked for me on
 Paul> 'ggv'.
Works for me (also ggv) - what did you do, break up paths longer than
a certain size into multiple paths? I need to do the same for agg to
fix Jin-chung's bug.
JDH

Fernando Perez wrote:
> Paul Barrett wrote:
> 
>> I found a bug in the Y-axis scaling. See the attached PS file. The 
>> Y-axis scale should go from 0. to 2.0e-11 (in ergs/cm**2/s/Angstrom). 
>> Instead it is zeros. Anyone having experience with the scaling code 
>> want to fix this?
>>
>> For those interested, this is a section of the far ultraviolet 
>> spectrum of the variable star SS Cygni (SS Cyg for short) taken by 
>> NASA's Far Ultraviolet Spectroscopic Explorer (FUSE for short).
> 
> 
> Well, I actually tried to see it but gv (Fedora Core 2) chokes on the 
> file: CPU utilization goes to 100% after displaying the axes, labels, 
> and a tiny bit of the graph. I killed it after a while.
> 
> Are there known problems with the Postscript generated by matplotlib? 
> Can it produce EPS directly (better for publication)?
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'.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

>>>>> "Vittorio" == Vittorio Palmisano <re...@em...> writes:
 Vittorio> Hi, The debian package has a new address due to recent
 Vittorio> changes on mentors.debian.net. Instructions for
 Vittorio> installing are now:
 Vittorio> --8<----------------------------------------------------------------------
 Vittorio> * add this lines to your /etc/apt/sources.list: deb
 Vittorio> http://anakonda.altervista.org/debian packages/ deb-src
 Vittorio> http://anakonda.altervista.org/debian sources/ * then
 Vittorio> run: # apt-get update # apt-get install
 Vittorio> python-matplotlib python-matplotlib-doc
 Vittorio> --8<----------------------------------------------------------------------
Thanks Vittorio,
Just for your information, matplotlib no longer requires ttfquery so
you may want to remove this from the debian matplotlib distro.
Thanks!
JDH

On Sat, 2004年08月14日 at 11:42,
mat...@li... wrote:
> Hi, I searched for material related to this, but didn't find any, so I 
> hope this isn't a repeat. One feature that has been missing from 
> matplotlib that I find really useful is to print my graphs (I generate a 
> lot, and generally want a hard copy, but not a lot of random files lying 
> around). While on a unix system this is easy to do, I realize it is 
> rather difficult to make crossplatform. So instead I've been hacking the 
> source and adding my own button in. However, with each release this can 
> get a bit tiresome, so the idea occured to me that it would be nice if I 
> have a function to add buttons to the toolbar that could then run 
> arbritrary code.
> 
> I can submit my code if anyone is interested (it's a very rough hack, 
> and only for the GTK backend), but the idea is that in my own code I can 
> just do:
> 
> def myprint(*args, **kwargs):
> fd, path = tempfile.mkstemp(suffix=".eps", dir="/tmp")
> 
> savefig(path)
> print "lpr %s" % path
> os.system("lpr %s" % path)
> 
> os.close(fd)
> os.unlink(path)
> 
> 
> and later on:
> 
> add_toolbar_button("print", "prints figure", gtk.STOCK_PRINT, myprint)
> 
> I was curious as to what other people thought of this, and whether it 
> had a chance of ending up in matplotlib (being able to add other widgets 
> besides buttons would be extra cool).
Perhaps the .matplotlibrc file could have lines like
printcommand: None
printcommand: '"lpr %s" % path'
And if printcommand is not None an extra toolbar button is created which
calls 
os.system(printcommand)
to print the file.
Steve

Hi, I searched for material related to this, but didn't find any, so I 
hope this isn't a repeat. One feature that has been missing from 
matplotlib that I find really useful is to print my graphs (I generate a 
lot, and generally want a hard copy, but not a lot of random files lying 
around). While on a unix system this is easy to do, I realize it is 
rather difficult to make crossplatform. So instead I've been hacking the 
source and adding my own button in. However, with each release this can 
get a bit tiresome, so the idea occured to me that it would be nice if I 
have a function to add buttons to the toolbar that could then run 
arbritrary code.
I can submit my code if anyone is interested (it's a very rough hack, 
and only for the GTK backend), but the idea is that in my own code I can 
just do:
def myprint(*args, **kwargs):
 fd, path = tempfile.mkstemp(suffix=".eps", dir="/tmp")
 savefig(path)
 print "lpr %s" % path
 os.system("lpr %s" % path)
 os.close(fd)
 os.unlink(path)
and later on:
add_toolbar_button("print", "prints figure", gtk.STOCK_PRINT, myprint)
I was curious as to what other people thought of this, and whether it 
had a chance of ending up in matplotlib (being able to add other widgets 
besides buttons would be extra cool).
Abe
p.s. Matplotlib is great! Never having to go near matlab again makes me 
happy just thinking about it. Thanks for the great work!