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