matplotlib-users Mailing List for matplotlib

>> once running, it's not working quite right: the tooltip always is at the 
>> bottom of the Window, though it does track the X location.
> 
> Hm, dunno. I'm running win32 (winxp), Python 2.4.3.

> Maybe try updating your wx install.

I've tried with 2.6.3, same result.

I think this is a platform issue: I expect that GTK is putting the 
tooltip at the bottom of the wx.Window it's on. this is really to bad, 
as with larger Windows, that might not be what you want.

In fact, I have a need to add tooltips to a wx.lib.floatcanvas based 
app, a I need to be able to place them where I need. I guess I'll send a 
note to wxpython-users about this.

I've enclosed a wxpython tiny test app, to isolate matplotlib issues. It 
has the same behavior. does the tooltip follow the mouse on Windows (or 
OS-X)

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

> mpl.use('WXAgg') has to come before "import pylab"

Right, my mistake. My mpl defaults to wxagg, so I didn't notice that.
I'll post an updated one to the devel list.

> once running, it's not working quite right: the tooltip always is at the 
> bottom of the Window, though it does track the X location.

Hm, dunno. I'm running win32 (winxp), Python 2.4.3.
>>> wx.__version__
'2.6.3.3'
>>> matplotlib.__version__
'0.87.5'

Maybe try updating your wx install.

> oddly it looks likeit's getting it's coords in figure units (0 to 1), 
> whcih shouldn't work with a wxWindow.

That's as expected. It's using MPL's event.xdata and event.ydata
attributes, which are in data coords. If you want pixel coordinates, you
can use event.x and event.y (I think).

Martin

Paul-Michael Agapow wrote:
> there was a previous wx installation on my machine. 
> (Possibly installed by some super-pack or along with some other 
> library.)

Apple put it there. they included a version of wxpython with their 
Python install.

It's out of date, but pretty coll that they did it.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Martin Spacek wrote:
> Attached is an example file of 
> what I've got running now. It should run on its own. A wx tooltip pops 
> up whenever the mouse is over the axes.

cool.

I had to make a change to get it to run:

mpl.use('WXAgg') has to come before "import pylab"

once running, it's not working quite right: the tooltip always is at the 
bottom of the Window, though it does track the X location.

oddly it looks likeit's getting it's coords in figure units (0 to 1), 
whcih shouldn't work with a wxWindow.

Also, I'm getting the tooltip even when the window doesnot have focus 
and is under other windows -- at least when the mouse is over an exposed 
part of the window. That's probably a wx issue.

Python 2.4.3
 >> wx.__version__
'2.6.3.0'
 >>> matplotlib.__version__
'0.87.5'

wxGTK on on Fedora core 4 linux.


-Chris





-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

> Have you thought about combining the dendrogram with a
> heatmap/colormap (e.g.
> http://www2.warwick.ac.uk/fac/sci/moac/currentstudents/peter_cock/python/heatmap/)?
> Could ClusterPlot be combined with pcolor() to do this?

To be honest, I haven't thought about doing anything like this.  While 
I'm using the Pycluster package to do my cluster analysis, I'm actually 
doing research in Physics Education, not genetics.  As a result, I've 
never even seen diagrams like the one shown in the above link before. 
Looking at it, however, I imagine that with the judicious use of 
subplots, ClusterPlot could create the dendrograms in those images. 
Once direction control is added to ClusterPlot, that is.

At this point I have thought about only two further extensions to 
ClusterPlot.  The first is the afore mentioned one: allowing control of 
the direction of the dendrogram.  Once that's implemented, I'd consider 
the code to be out of the beta stage.  The other extension would be a 
modification to the coordinates function so that the vertical 
coordinates of the dendrogram don't have to follow the Pycluster 
distances in the tree.  Pycluster doesn't support having anything other 
than a distance measure in that slot.  Now, while Pycluster does have 8 
different distance measures, I can imagine cases where one would prefer 
to spread the tree by a dissimilarity measure or some other metric. 
This modification should be simple enough to make, so it'll probably be 
included in the next update (which might come before full release).

Finally, concerning the license discussion, I've posted version 0.6 
which is released under the BSD-style license.  Version 0.5, with its 
GPL license has been removed from the download site.

http://www.umit.maine.edu/~r.springuel/000CCFE8-80000018/
-- 

R. Padraic Springuel
Teaching Assistant
Department of Physics and Astronomy
University of Maine
Bennett 309
Office Hours: Wednesday 2-3pm

I chose the GPL because it was the open source license I was aware of 
and didn't realize that it would create problems with reusability of the 
code.  It is not my intention to restrict people from reusing the code. 
  Indeed, I'd much prefer that people did reuse the code.  Since that 
appears to mean switching to a BSD style license, I'll make that switch.
-- 

R. Padraic Springuel
Teaching Assistant
Department of Physics and Astronomy
University of Maine
Bennett 309
Office Hours: Wednesday 2-3pm

>>>>> "Yannick" == Yannick Copin <y....@ip...> writes:

    Yannick> Hi,
    >>>>>>> >>>>> "David" == David Huard <dav...@gm...>
    >>>>>>> writes:
    >>
    David> Hi, I'm a little bit lost with respect to setting the
    David> resolution of images saved in png.  The matplotlibrc file
    David> sets the dpi to 80, but the default keyword argument of
    David> savefig is set to 150. Thus, changing the rc setting to
    David> dpi=300 does not modify savefig's default behaviour.  Is
    David> there a way to set a default dpi that would be used when
    David> calling savefig ?
    >> 
    >> 
    >> Have you tried modifying the rc setting
    >> 
    >> savefig.dpi : 100 # figure dots per inch

    Yannick> On a related issue: when exporting a figure from the
    Yannick> tkagg backend (using the appropriate button) to PNG, the
    Yannick> dpi is arbitrirarily set to 300 (see backend_tkagg.py in
    Yannick> NavigationToolbar2TkAgg.save_figure):

    Yannick> self.canvas.print_figure(fname, dpi=300)

    Yannick> I think it should honor the savefig.dpi rc setting:

    Yannick> self.canvas.print_figure(fname,
    Yannick> dpi=rcParams['savefig.dpi'])

Yep -- this is a bug in my view.  pylab.savefig and fig.avefig respect
the setting, but canvas.print_figure did not.  I updated the following
backends:

Sending        matplotlib/lib/matplotlib/backend_bases.py
Sending        matplotlib/lib/matplotlib/backends/backend_agg.py
Sending        matplotlib/lib/matplotlib/backends/backend_fltkagg.py
Sending        matplotlib/lib/matplotlib/backends/backend_gtk.py
Sending        matplotlib/lib/matplotlib/backends/backend_gtkagg.py
Sending        matplotlib/lib/matplotlib/backends/backend_qt4agg.py
Sending        matplotlib/lib/matplotlib/backends/backend_qtagg.py
Sending        matplotlib/lib/matplotlib/backends/backend_template.py
Sending        matplotlib/lib/matplotlib/backends/backend_tkagg.py
Sending        matplotlib/lib/matplotlib/backends/backend_wx.py
Sending        matplotlib/lib/matplotlib/backends/backend_wxagg.py
Sending        matplotlib/lib/matplotlib/figure.py

Those of you with svn access please give it a test drive on your
favorite backends to make sure it is behaving properly.  I was able to
test several...

JDH

Spot on. Thanks Charles - that did the trick (setting WX_CONFIG to  
point to the right place). I had the universal wxpython installed but  
unbeknownst to me there was a previous wx installation on my machine.  
(Possibly installed by some super-pack or along with some other  
library.) Setting the environmental variable WX_CONFIG to the correct  
location (/usr/local/lib/wxPython-unicode-2.6.3.3/bin/wx-config)  
before the build sorted things out.

As an aside, the spurious error messages generated in the build stage  
(warning: "M_PI" redefined,  /usr/local/lib/libgcc_s.10.4.dylib does  
not contain an architecture that matches the specified -arch flag:  
ppc, etc.) aren't helpful and may hide any genuine problems. It would  
be nice to have them go away.

Thanks again

p

>> After some progress in installing matplotlib (after solving the numpy
>> problem, thanks), I've hit another obstacle. Again, perhaps  
>> someone will
>> recognise the symptoms or suggest the next place to look. The  
>> technical set
>> up: OSX 10.4, MPL 0.87.5, numeric, numarray and  numpy 1.0b5  
>> installed,
>> intel MacBook.
>>
>> The issue: matplotlib installs but when pylab is imported, I get: :
>>
>>     14:28:56: Debug: ../src/common/object.cpp(224): assert
>> "sm_classTable->Get(m_className) == NULL" failed: class
>> already in RTTI table - have you used IMPLEMENT_DYNAMIC_CLASS()  
>> twice (may
>> be by linking some object module(s) twice)?
>>     ../src/common/object.cpp(224): assert
>> "sm_classTable->Get(m_className) == NULL" failed: class
>> already in RTTI table - have you used IMPLEMENT_DYNAMIC_CLASS()  
>> twice (may
>> be by linking some object module(s) twice)?
>>     Trace/BPT trap
>>
>> and then dumped to the CLI.  ``sm_classTable`` appears to be  
>> defined in  the
>> wxagg backend.
>
> Do you have the universal wxpython installed?  If so, make sure you
> set WX_CONFIG to point to the correct wx-config executable.

--
Dr Paul-Michael Agapow, VieDigitale / Institute of Animal Health
pm...@vi... / pau...@bb...

On 9/12/06, John Hunter <jdh...@ac...> wrote:

Minor correction

>   license. Fernando Perez did this with ipython, which was released
>   under the LGPL and then re-released under a BSD license to ease
>   integration with scipy and other enthought products. The LGPL is
                    ^^^
                     matplotlib, scipy and...

Integration and free back-and-forth code sharing with you was one of
the main factors behind that decision.

And just to provide a datapoint confirming John's argument, ipython
was one of those cases where I chose LGPL out of pure ignorance and
incomplete understanding.

Regards,

f

Thanks I got it working now. I did not read the instructions properly. I was 
not using the
proper backend. I was using one of the image backends when I should have 
been using
the GUI backend.

http://matplotlib.sourceforge.net/backends.html

Henock 

Try a different backend. If one doesn't work, something went wrong during the 
installation (it happened to me a couple of times, reinstalling from scratch 
seemed to have solve the pb).

>>>>> "R" =3D=3D R Padraic Springuel <R.S...@um...> writes:

    R> St=E9fan suggested that I include an example script to show
    R> people what the package could do.  I thought this was a good
    R> idea, so I wrote one and have uploaded a new version of the
    R> package with the example script.  I've also added copyright and
    R> license information, for those that care. =20

Hi this looks very nice.  Are you sure you want to go with GPL?
pycluster and the C clustering license, as well as matplotlib, scipy,
and Numeric/numpy, are all based on BSD/PSF compatible licenses, and
so none of these projects can reuse your code if it is GPL.

Here is my "licensing pitch" on why I encourage people not to use the
GPL, written for another project but applicable here...

  I'll start by summarizing what many of you already know about open
  source licenses. I believe this discussion is broadly correct,
  though it is not a legal document and if you want legally precise
  statements you should reference the original licenses cited
  here. The Open-Source-Initiative is a clearing house for OS
  licenses, so you can read more there.

  The two dominant license variants in the wild are GPL-style and
  BSD-style. There are countless other licenses that place specific
  restrictions on code reuse, but the purpose of this document is to
  discuss the differences between the GPL and BSD variants,
  specifically in regards to my experience developing matplotlib and
  in my discussions with other developers about licensing issues.

  The best known and perhaps most widely used license is the GPL,
  which in addition to granting you full rights to the source code
  including redistribution, carries with it an extra obligation. If
  you use GPL code in your own code, or link with it, your product
  must be released under a GPL compatible license. I.e., you are
  required to give the source code to other people and give them the
  right to redistribute it as well. Many of the most famous and widely
  used open source projects are released under the GPL, including
  linux, gcc and emacs.

  The second major class are the BSD-style licenses (which includes
  MIT and the python PSF license). These basically allow you to do
  whatever you want with the code: ignore it, include it in your own
  open source project, include it in your proprietary product, sell
  it, whatever. python itself is released under a BSD compatible
  license, in the sense that, quoting from the PSF license page

  There is no GPL-like "copyleft" restriction. Distributing
  binary-only versions of Python, modified or not, is allowed. There
  is no requirement to release any of your source code. You can also
  write extension modules for Python and provide them only in binary
  form.

  Famous projects released under a BSD-style license in the permissive
  sense of the last paragraph are the BSD operating system, python and
  TeX.

  I believe the choice of license is an important one, and I advocate
  a BSD-style license. In my experience, the most important commodity
  an open source project needs to succeed is users. Of course, doing
  something useful is a prerequisite to getting users, but I also
  believe users are something of a prerequisite to doing something
  useful. It is very difficult to design in a vacuum, and users drive
  good software by suggesting features and finding bugs. If you
  satisfy the needs of some users, you will inadvertently end up
  satisfying the needs of a large class of users. And users become
  developers, especially if they have some skills and find a feature
  they need implemented, or if they have a thesis to write. Once you
  have a lot of users and a number of developers, a network effect
  kicks in, exponentially increasing your users and developers. In
  open source parlance, this is sometimes called competing for mind
  share.

  So I believe the number one (or at least number two) commodity an
  open source project can possess is mind share, which means you want
  as many damned users using your software as you can get. Even though
  you are giving it away for free, you have to market your software,
  promote it, and support it as if you were getting paid for it. Now,
  how does this relate to licensing, you are asking?

  Many software companies will not use GPL code in their own software,
  even those that are highly committed to open source development,
  such as enthought, out of legitimate concern that use of the GPL
  will "infect" their code base by its viral nature. In effect, they
  want to retain the right to release some proprietary code. And in my
  experience, companies make for some of the best developers, because
  they have the resources to get a job done, even a boring one, if
  they need it in their code. Two of the matplotlib backends (FLTK and
  WX) were contributed by private sector companies who are using
  matplotlib either internally or in a commercial product -- I doubt
  these companies would have been using matplotlib if the code were
  GPL. In my experience, the benefits of collaborating with the
  private sector are real, whereas the fear that some private company
  will "steal" your product and sell it in a proprietary application
  leaving you with nothing is not.

  There is a lot of GPL code in the world, and it is a constant
  reality in the development of matplotlib that when we want to reuse
  some algorithm, we have to go on a hunt for a non-GPL version. Most
  recently this occurred in a search for a good contouring
  algorithm. I worry that the "license wars", the effect of which are
  starting to be felt on many projects, have a potential to do real
  harm to open source software development. There are two unpalatable
  options. 1) Go with GPL and lose the mind-share of the private
  sector 2) Forgo GPL code and retain the contribution of the private
  sector. This is a very tough decision because their is a lot of very
  high quality software that is GPL and we need to use it; they don't
  call the license viral for nothing.

  The third option, which is what is motivating me to write this, is
  to convince people who have released code under the GPL to
  re-release it under a BSD compatible license. Package authors retain
  the copyright to their software and have discretion to re-release it
  under a license of their choosing. Many people choose the GPL when
  releasing a package because it is the most famous open source
  license, and did not consider issues such as those raised here when
  choosing a license. When asked, these developers will often be
  amenable to re-releasing their code under a more permissive
  license. Fernando Perez did this with ipython, which was released
  under the LGPL and then re-released under a BSD license to ease
  integration with scipy and other enthought products. The LGPL is
  more permissive than the GPL, allowing you to link with it
  non-virally, but many companies are still loath to use it out of
  legal concerns, and you cannot reuse LGPL code in a proprietary
  product.

  So I encourage you to release your code under a BSD compatible
  license, and when you encounter an open source developer whose code
  you want to use, to do the same. Feel free to forward this document
  on them.

  Comments, suggestions for improvements, corrections, etc, should be
  sent to jdh...@ac...

Hi,

Looks very interesting. Is there any chance that this will be
eventually included in MPL? Or at least have a license similar to MPL?

Have you thought about combining the dendrogram with a
heatmap/colormap (e.g.
http://www2.warwick.ac.uk/fac/sci/moac/currentstudents/peter_cock/python/he=
atmap/)?
Could ClusterPlot be combined with pcolor() to do this?

Mike

On 9/12/06, R. Padraic Springuel <R.S...@um...> wrote:
> St=E9fan suggested that I include an example script to show people what
> the package could do.  I thought this was a good idea, so I wrote one
> and have uploaded a new version of the package with the example script.
>   I've also added copyright and license information, for those that
> care.  The most recent version is 0.5 and is downloadable from the same
> site as before:
>
> http://www.umit.maine.edu/~r.springuel/000CCFE8-80000018/
> --
>
> R. Padraic Springuel
> Teaching Assistant
> Department of Physics and Astronomy
> University of Maine
> Bennett 309
> Office Hours: By Appointment only during the Summer
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Thanks for the help Ken and Christopher! Attached is an example file of 
what I've got running now. It should run on its own. A wx tooltip pops 
up whenever the mouse is over the axes. The tooltip's hangs obediently 
off of the bottom right of the mouse cursor. Its string is updated to 
reflect the current position of the mouse in data coordinates.

I'll make a post to the devel list, maybe get this added to the MPL 
examples.

Cheers,

Martin