matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
> def draw_markers(self, gc, path, x, y, transform):
>
It might be worth generalizing this to take some optional array/scalar
arguments to apply marker by marker scaling (or even independent x/y
scaling) as well as overrides to some gc items (e.g. color). This doesn't
need to be done right away, but may provide some very useful capability
(e.g., error bars could be done as markers if y or x size could be scaled
for every x,y location.
Perry

>>>>> "Matt" == Matt Newville <new...@ca...> writes:
 Matt> Hi, I'm working on GUI apps using matplotlib's class library
 Matt> with both WXAgg and TkAgg backends, and am having a
 Matt> love/hate relationship with the FigureCanvase.mpl_connect()
 Matt> methods. These return a platform-neutral, matplotlib-aware
 Matt> Event, which is great for dealing with the Plot canvas, but
 Matt> swallow the native GUI event, complicating working with the
 Matt> GUI toolkit.
Hmm, I thought the point of doing the Skip call
 def _onKeyDown(self, evt):
 """Capture key press."""
 key = self._get_key(evt)
 evt.Skip()
 FigureCanvasBase.key_press_event(self, key)
would be to prevent the event from being swallowed. So you should be
able to get those events if you've made a second connection, right?
If so, what you are arguing for is the ability to get the GUI event
within the mpl event because this is more convenient than making two
connections. Is that right?
You can always make the change with guiEvent=None in the
__init__function so other backends can add it when/if they want it.
It looks like a good idea to me to add it across backends, though.
JDH

Hi, 
I'm working on GUI apps using matplotlib's class library with
both WXAgg and TkAgg backends, and am having a love/hate
relationship with the FigureCanvase.mpl_connect() methods. 
These return a platform-neutral, matplotlib-aware Event, which
is great for dealing with the Plot canvas, but swallow the
native GUI event, complicating working with the GUI toolkit. 
It seems simple enough to include the native event structure as
a member of the the mpl event. That would allow the
backend-specific code to use these backend-specific events. I
think this could be as simple as adding an optional keyword arg
'gui_event' to KeyEvent.__init__, LocationEvent.__init__, and
MouseEvent._init__, and then passing along the native event
objects in the backends. That would simply add a GUI-specific
attribute 'gui_event' to the mpl event, breaking no existing
code or the functionality of the Toolbars, but allow those of us
who want more event information to have it.
Does this change seem reasonable? It would involve many small
changes in backend_bases.py and backends/backend*.py. I'd be
willing to implement it, but am reluctant to step on anyone
else's toes, especially for the different backends....
Thanks,
--Matt Newville <newville @ cars.uchicago.edu>

Hey again,
I was having trouble getting py2exe to include all the libraries in 
matplotlib so I created a very simple GTK + matplotlib program to do 
some testing. The weird thing is that before the reformat + reinstall 
of my Windows desktop this very process was working great.
Included in the attachments is the output of >python setup.py py2exe in 
the file py2exe.out.
Next is the setup.py file just to prove that it should work (setup.py).
Last is the sample application test.py used to demonstrate the py2exe 
failure.
What you will need to do is copy the .dlls from your GTK\bin directory 
to the local copy of the GTK\lib directory (all of this under the dist 
directory that py2exe produces). Also be sure to copy the GTK\etc 
directory there as well and you should be able to get the GTK part up 
and running.
The problem code is the following import statements:
import matplotlib
matplotlib.use('GTKAgg')
import matplotlib.backends.backend_gtkagg
import matplotlib.pylab
I would attach my whole work directory, but that might have been too 
large for the mailing list (the GTK part of it is several MBs alone).
Joe

John Hunter wrote:
> And I think we should seriously consider using enthought traits rather
> than rolling our own. I understand that a C extension doesn't work
> for ipython, but matplotlib has enough extension code that one extra
> piece wouldn't hurt too much. I haven't had much too much luck with
> the GUI component of traits -- it only works with WX currently and
> even then it was flaky on OSX.
> 
> I'm not totally opposed to rolling our own traits-light (whatever we
> call it) because its a basic application of properties, but we would
> probably end up reinventing a fair amount that enthought has already
> done, and my guess is there version will be faster, more feature rich
> and better documented (they have about 100 page user's guide for
> traits2). And we've been accused of failing to build on other
> people's efforts in scipy and chaco, so I think we should be sensitive
> to reinventing another wheel that enthought has put a lot of work
> into.
> 
> The observer pattern would certainly be useful, delegation probably as
> well. 
> 
> We come full-circle back to the same point -- we would like to see a
> free standing traits package outside of envisage and scipy distutils
> that we could simply install w/o having to maintain a separate tree
> that we factor out. This has been mentioned a few times, but I'll
> bring this up on envisage dev again.
> 
> This would also smooth the path toward making matplotlib an envisage
> plugin.
> 
> Sorry if you feel pulled in many directions Abraham -- your work is
> very nice and may be the right way to go. Whether we decide to use
> your properties or enthought traits, the rc framework you've setup
> appears to be readily usable with either.
> 
All well stated and with which I wholeheartedly agree. A lot of work
has gone into traits. I also agree that the gui aspect of it is not
something one would want to use until it was truly made multi-GUI 
supported.
Perry

Hi. Here are a couple thoughts on the problem:
(1) Can we come up with a list of what capabilities we want the config 
library to do? I think it will be difficult to come to a definite plan 
without some sort of specs. Currently the prototype uses traits-lite to 
act as a sentinal to check that the assignment is valid. So if 
assignment-validation is all that is required, it seems a very small 
subsection of the Traits package.
(2) Using the traits package does have several difficulties: (a) 
currently it is difficult to find much written about it (I did not know 
it existed until you pointed it out), (b) it's API is currently changing 
(?), (c) will this require people to download and install SciPy as well? 
Or will it be distributed as a separate library?
(3) I agree. I think the current prototype framework will not need more 
than a couple hours of work to allow either method. Because of this, 
perhaps it's best to go the traits-lite route, until exactly what is 
happening with Traits2 becomes clear .. as long as we can make sure the 
main API doesn't change, it shouldn't affect the end user.
(4) One last thought. Maybe if we can spec out exactly what is required 
of whatever Traits package we use, we can provide a wrapper API so 
either one can be used. We can prefer the Traits package, but if it is 
not used, we can instead use our lite version.
Abe
John Hunter wrote:
>And I think we should seriously consider using enthought traits rather
>than rolling our own. I understand that a C extension doesn't work
>for ipython, but matplotlib has enough extension code that one extra
>piece wouldn't hurt too much. I haven't had much too much luck with
>the GUI component of traits -- it only works with WX currently and
>even then it was flaky on OSX.
>
>I'm not totally opposed to rolling our own traits-light (whatever we
>call it) because its a basic application of properties, but we would
>probably end up reinventing a fair amount that enthought has already
>done, and my guess is there version will be faster, more feature rich
>and better documented (they have about 100 page user's guide for
>traits2). And we've been accused of failing to build on other
>people's efforts in scipy and chaco, so I think we should be sensitive
>to reinventing another wheel that enthought has put a lot of work
>into.
>
>The observer pattern would certainly be useful, delegation probably as
>well. 
>
>We come full-circle back to the same point -- we would like to see a
>free standing traits package outside of envisage and scipy distutils
>that we could simply install w/o having to maintain a separate tree
>that we factor out. This has been mentioned a few times, but I'll
>bring this up on envisage dev again.
>
>This would also smooth the path toward making matplotlib an envisage
>plugin.
>
>Sorry if you feel pulled in many directions Abraham -- your work is
>very nice and may be the right way to go. Whether we decide to use
>your properties or enthought traits, the rc framework you've setup
>appears to be readily usable with either.
>
>JDH
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
>

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
 Perry> If I'm not mistaken, those are the names that the Trait
 Perry> package used originally! They changed the name because of
 Perry> potential confusion with Python properties. Isn't that
 Perry> still an issue?
And I think we should seriously consider using enthought traits rather
than rolling our own. I understand that a C extension doesn't work
for ipython, but matplotlib has enough extension code that one extra
piece wouldn't hurt too much. I haven't had much too much luck with
the GUI component of traits -- it only works with WX currently and
even then it was flaky on OSX.
I'm not totally opposed to rolling our own traits-light (whatever we
call it) because its a basic application of properties, but we would
probably end up reinventing a fair amount that enthought has already
done, and my guess is there version will be faster, more feature rich
and better documented (they have about 100 page user's guide for
traits2). And we've been accused of failing to build on other
people's efforts in scipy and chaco, so I think we should be sensitive
to reinventing another wheel that enthought has put a lot of work
into.
The observer pattern would certainly be useful, delegation probably as
well. 
We come full-circle back to the same point -- we would like to see a
free standing traits package outside of envisage and scipy distutils
that we could simply install w/o having to maintain a separate tree
that we factor out. This has been mentioned a few times, but I'll
bring this up on envisage dev again.
This would also smooth the path toward making matplotlib an envisage
plugin.
Sorry if you feel pulled in many directions Abraham -- your work is
very nice and may be the right way to go. Whether we decide to use
your properties or enthought traits, the rc framework you've setup
appears to be readily usable with either.
JDH

John Hunter wrote"
>
> I don't think we should use the name Trait or HasTrait, since that
> will confuse people into thinking we are using enthought traits
> (Property and HasProperty ?) 
> 
If I'm not mistaken, those are the names that the Trait package used
originally! They changed the name because of potential confusion with
Python properties. Isn't that still an issue?
Perry 

> Which leads me to question one for the backend maintainers: 
> can you support a draw_path method? I"m not sure that GTK and 
> WX can. I have no idea about FLTK, and QT, but both of these 
> are Agg backends so it doesn"t matter. All the Agg backends
> automagically get these for free. I personally would be 
> willing to lose the native GTK and WX backends.
Hmm, it looks to me like WX is technically a 'No', but that
MOVETO and LINETO can be easily emulated (wxDC.Line takes a
start and stop position). That might defeat the purpose, but
it's doable. I don't see how to do ENDPOLY/Fill without knowing
the start of the polygon, which makes it seem a whole lot like
draw_polygon() to me. Perhaps I'm missing something obvious,
but it seems like you'd want to keep some state information (pen
attributes, etc) around?
Anyway, I'm definitely OK with not having the pure WX backend. 
AFAIK, the only consideration for these is speed, and WXAgg is
already much faster than WX. A significant fraction of the time
to create a WXAgg image is in generating the Agg image, so any
work towards speeding up image rendering will improve WXAgg and
all Agg backends. To me, that seems like the way to go!
--Matt Newville <newville @ cars.uchicago.edu>

On Tue, 2005年02月08日 at 08:51 -0600, John Hunter wrote:
> Which leads me to question one for the backend maintainers: can you
> support a draw_path method? I'm not sure that GTK and WX can. I have
> no idea about FLTK, and QT, but both of these are Agg backends so it
> doesn't matter. All the Agg backends automagically get these for
> free. I personally would be willing to lose the native GTK and WX
> backends.
I don't think that GTK can support a draw_path method at the moment, but
when GTK starts to use Cairo it should.
 
> Also, any feedback on the idea of removing GD, native GTK and native
> WX are welcome. I'll bounce this off the user list in any case.
The GTK+ developers have recently announced that Cairo is now a GTK+
dependency
http://www.osnews.com/story.php?news_id=9609
Pango is currently being updated to use Cairo, and later GDK and GTK+
are expected to support/use Cairo. It looks like GTK rendering is in the
process of being improved dramatically, so I'd recommend keeping the
native GTK backend a bit longer to see what happens.
Also it means we can expect all future Linux distributions (that include
GTK+ 2.8 or later) to include Cairo.
Regards
Steve