matplotlib-devel Mailing List for matplotlib

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