matplotlib-devel Mailing List for matplotlib

Thanks John,
Everything seems fine.
Thanks again,
-JJ
On Wed, Sep 17, 2008 at 4:53 PM, John Hunter <jd...@gm...> wrote:
> On Wed, Sep 17, 2008 at 2:49 PM, Jae-Joon Lee <lee...@gm...> wrote:
>
>>>> I uploaded my patch.
>>>>
>>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2116614&group_id=80706&atid=560722
>
> OK, I've applied it. I reformatted some of the docstrings and
> incorporated a bunch of the comments into the docstrings because they
> will probably be helpful there to users reading the docs to figure out
> what is going on. Let me know if this creates any problems, and
> thanks again for the very nice patch and examples.
>
> JDH
>

Mike et al.,
You can ignore my message. Something is wrong with my numpy 
installation--an old version is being found. The fact that the problem 
started when I updated sphinx, and it did something with easy_install, 
makes me wonder whether that is what started the trouble. I haven't 
figured it out yet.
Eric
Eric Firing wrote:
> Mike,
> 
> After updating sphinx to 66492 from svn, I can't build the mpl docs:
> 
> efiring@manini:~/programs/py/mpl/mpl_trunk/doc$ python make.py
> Extension error:
> Could not import extension mathmpl (exception: No module named ma)
> Building HTML failed.
> 
> Any idea what the problem is?
> 
> Thanks.
> 
> Eric
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hello,
Attached is a small patch to add a simple color mix operation support.
For example, "red!30!white" mixes 30% of red with 70% of white. The
syntax is borrowed from latex xcolor package
(http://www.ukern.de/tex/xcolor.html).
I found it quite handy with the fancy box thing.
plt.text(0.6, 0.5, "test", size=50, rotation=30.,
 bbox = dict(boxstyle="round",
 fc="orange!20!white", # 20% orange + 80% white
 ec="orange!50!white", # 50 % orange + 50% white
 )
 )
plt.text(0.5, 0.4, "test", size=50, rotation=-30.,
 bbox = dict(boxstyle="square",
 fc="aqua!50!green!20!white",
 ec="green!40!white",
 )
 )
Any chance this could be included in matplotlib?
Regards,
-JJ

Mike,
After updating sphinx to 66492 from svn, I can't build the mpl docs:
efiring@manini:~/programs/py/mpl/mpl_trunk/doc$ python make.py
Extension error:
Could not import extension mathmpl (exception: No module named ma)
Building HTML failed.
Any idea what the problem is?
Thanks.
Eric

On Wed, Sep 17, 2008 at 2:49 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>> I uploaded my patch.
>>>
>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2116614&group_id=80706&atid=560722
OK, I've applied it. I reformatted some of the docstrings and
incorporated a bunch of the comments into the docstrings because they
will probably be helpful there to users reading the docs to figure out
what is going on. Let me know if this creates any problems, and
thanks again for the very nice patch and examples.
JDH

s
On Wed, Sep 17, 2008 at 2:50 PM, Jae-Joon Lee <lee...@gm...> wrote:
> One thing I forgot to mention is that, in the Text class, draw()
> method calls _draw_bbox() method. If I call the _draw_bbox() methods
> after gc in draw() is created, then _draw_bbox call somehow changes
> the gc in the original draw() method, which I think is not supposed to
> happen. I haven't looked at this carefully, but this might only happen
> in some specific backends (I'm using GtkCairo). Anyhow, as a
> workaround, in the draw() method, _draw_bbox() is called before the gc
> is created.
I am not sure why the gc is being modified, but an alternative is to
get a new gc and then copy the properties
 newgc = renderer.new_gc()
 newgc.copy_properties(oldgc)
This might be a less brittle solution since in the distant future we
may not remember why the drawing order had t be the way it is.
JDH
JDH

One thing I forgot to mention is that, in the Text class, draw()
method calls _draw_bbox() method. If I call the _draw_bbox() methods
after gc in draw() is created, then _draw_bbox call somehow changes
the gc in the original draw() method, which I think is not supposed to
happen. I haven't looked at this carefully, but this might only happen
in some specific backends (I'm using GtkCairo). Anyhow, as a
workaround, in the draw() method, _draw_bbox() is called before the gc
is created.
On Wed, Sep 17, 2008 at 3:49 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Thanks John,
>
> I made a single diff file and uploaded it.
>
> https://sourceforge.net/tracker/index.php?func=detail&aid=2116614&group_id=80706&atid=560722
>
> Regards,
>
> -JJ
>
>
>
>
>
> On Wed, Sep 17, 2008 at 3:01 PM, John Hunter <jd...@gm...> wrote:
>> On Wed, Sep 17, 2008 at 1:30 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>> Hi,
>>>
>>> I uploaded my patch.
>>>
>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2116614&group_id=80706&atid=560722
>>
>>
>> Hi Jae Joon -- thanks for uploading this. I have read through it once
>> and it looks pretty good -- thanks for doing the extra work to
>> properly document the kwargs using the auto-property infrastructure.
>>
>> One request: could you submit the entire patch including the examples
>> as a single 'svn diff'? Then I can more easily apply it and test it.
>>
>> Thanks,
>> JDH
>>
>

Thanks John,
I made a single diff file and uploaded it.
https://sourceforge.net/tracker/index.php?func=detail&aid=2116614&group_id=80706&atid=560722
Regards,
-JJ
On Wed, Sep 17, 2008 at 3:01 PM, John Hunter <jd...@gm...> wrote:
> On Wed, Sep 17, 2008 at 1:30 PM, Jae-Joon Lee <lee...@gm...> wrote:
>> Hi,
>>
>> I uploaded my patch.
>>
>> https://sourceforge.net/tracker/index.php?func=detail&aid=2116614&group_id=80706&atid=560722
>
>
> Hi Jae Joon -- thanks for uploading this. I have read through it once
> and it looks pretty good -- thanks for doing the extra work to
> properly document the kwargs using the auto-property infrastructure.
>
> One request: could you submit the entire patch including the examples
> as a single 'svn diff'? Then I can more easily apply it and test it.
>
> Thanks,
> JDH
>

On Wed, Sep 17, 2008 at 1:44 PM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> Is anyone else seeing some odd messages when trying to use SVN right
> now? Here's what I see:
>
I just did an svn up w/o incident
JDH

On Wed, Sep 17, 2008 at 1:30 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Hi,
>
> I uploaded my patch.
>
> https://sourceforge.net/tracker/index.php?func=detail&aid=2116614&group_id=80706&atid=560722
Hi Jae Joon -- thanks for uploading this. I have read through it once
and it looks pretty good -- thanks for doing the extra work to
properly document the kwargs using the auto-property infrastructure.
One request: could you submit the entire patch including the examples
as a single 'svn diff'? Then I can more easily apply it and test it.
Thanks,
JDH

Hi,
Is anyone else seeing some odd messages when trying to use SVN right 
now? Here's what I see:
 >svn up
Error validating server certificate for 
'https://matplotlib.svn.sourceforge.net:443':
 - The certificate is not issued by a trusted authority. Use the
 fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: *.svn.sourceforge.net
 - Valid: from 2007年10月09日 14:15:07 GMT until 2008年12月08日 
15:15:07 GMT
 - Issuer: Equifax Secure Certificate Authority, Equifax, US
 - Fingerprint: fb:75:6c:40:58:ae:21:8c:63:dd:1b:7b:6a:7d:bb:8c:74:36:e7:8a
(R)eject, accept (t)emporarily or accept (p)ermanently? ^Csvn: OPTIONS 
of 
'https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib': 
Server certificate verification failed: issuer is not trusted 
(https://matplotlib.svn.sourceforge.net)
Thoughts?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi,
I uploaded my patch.
https://sourceforge.net/tracker/index.php?func=detail&aid=2116614&group_id=80706&atid=560722
I added a FancyBboxPatch class in the patches.py. And changed
text.Text class to support it. Two examples are attached with this
email. I hope I have put enough documentation, but if anything is not
clear, just let me know. Also see if the current interfaces are
acceptable.
I only have placed two kind of boxstyles. I'll add more eventually.
Regards,
-JJ
On Fri, Sep 12, 2008 at 5:21 PM, John Hunter <jd...@gm...> wrote:
> On Fri, Sep 12, 2008 at 2:46 PM, Jae-Joon Lee <lee...@gm...> wrote:
>> Thanks John,
>>
>> I think I'd better use a sf patch initially so that you or others can
>> review and improve it. I'll definitely need some help with
>> documentation as my English can be horrible sometime. On the other
>> hand, it would be much easier for me to do some maintenance work if I
>> can commit the changes directly. So, my sf id is "leejjoon" and it
>> will be great if you add me as a developer.
>
> OK, I added you as a developer, but you continue posting your patches
> here and we will be happy to review and comment on them as we have
> time.
>
>
>> I guess this fancy box thing can be used with other artist objects
>> also, although the legend object is an only object I can think of now.
>> And my personal inclination is put those support code into patches.py
>> and have a patch class around it, i.e., a FancyBoxPatch class which is
>> initialized with bbox-like object and draw a fancy box around the
>> given bbox. And let the Text and the Legend class use this
>> FancyBoxPatch. In the current matplotlib, both the Text and the Legend
>> class uses the Patch class for drawing a bbox. So how do you think?
>
> Yes, if you can generalize it to a Patch instance this will be more
> useful and then matplotlib.patches will be the place for it.
> I notice that your current TextBoxArtist does not actually derive from
> matplotlib.artist.Artist. If you intend it to be an Artist, you
> should explictly inherit and implement draw and other required methods
> (eg get_children if your Artist contains other artists)
>
>> What I also want to see in matplotlib is a fancy annotation. I have
>> some working code (although I'm planning some major code
>> reorganization) and willing to contribute it if there is an interest
>> (see the attached example). As you can easily guess, the fancy
>> annotation share some of its core with the fancy box. So if you're
>> also willing to include the fancy annotation things in matplotlib,
>> I'll put some more effort in the code reorganization so that it can
>> nicely fit in the current matplotlib classes.
>
> These examples look very nice too! Send in a patch when you have
> everything organized.
>
> JDH
>

John Hunter schrieb:
>> Second, I am using interactive mode and WXAgg in windows. So my startup
>> script does this:
>> import matplotlib as _mpl
>> _mpl.use('WXAgg')
>> import pylab as _p
>> _p.ion()
>> Before, when I would then type
>> gca().plot([1,2,1])
>> 
>
> I would not expect a draw here, since draw only happens on pylab
> commands. Eg _p.plot should trigger a draw, but not gca().plot
> because the latter is an axes method. I don't really know why it
> would have worked before, if it did. I would be pretty surprised if
> it did, actually.
> 
Older versions of the wx and wxagg backend indeed unnecessarily 
rerendered the figure (triggered a draw) very often - with every paint 
event. This has been fixed.
Gregor