matplotlib-devel Mailing List for matplotlib (Page 511)

Stephen Walton wrote:
> Fernando Perez wrote:
> 
> 
>>Well, it could be something like $HOME/.tex.cache, where $HOME can be 
>>determined via a routine like the below (this is what ipython uses to 
>>try and guess a sensible value for $HOME):
> 
> 
> I *like* it.

Though I'd personally vote for matplotlib holding $HOME/.matplotlib/ as a 
directory, and putting in there a tex.cache dir, the matplotlibrc file, and 
anything else it may need in the future.

I *really* don't like the idea that matplotlib will begin to put a bunch of 
differently named things under $HOME with various .foo names.  Ipython also 
started with .ipythonrc, and I quickly moved to an .ipython/ directory, where 
I stuff anything I need.  It's future-proof, clean, and gives an easy way for 
users to clean up if needed, without having to guess 'how many dot 
files/directories does this thing create'?

So if you were to ask for my opinion, I'd vote +100 on matplotlib moving to a 
single directory for holding *ALL* user and configuration data, which would 
default to $HOME/.matplotlib, and which could be overridden if the 
$MATPLOTLIBDIR environment variable is defined.  That's exactly how ipython 
works, so it must be the perfect solution :)

Cheers,

f

Fernando Perez wrote:

> Well, it could be something like $HOME/.tex.cache, where $HOME can be 
> determined via a routine like the below (this is what ipython uses to 
> try and guess a sensible value for $HOME):

I *like* it.

Stephen Walton wrote:
> Fernando Perez wrote:
> 
> 
>>It may be simpler than that:
> 
> 
> So os.environ does change the environment under Python and its 
> children.  The remaining question is what should TEXMFOUTPUT be?  
> /home/user/.tex.cache will not work across all platforms.

Well, it could be something like $HOME/.tex.cache, where $HOME can be 
determined via a routine like the below (this is what ipython uses to 
try and guess a sensible value for $HOME):

#----------------------------------------------------------------------------
class HomeDirError(Error):
     pass

def get_home_dir():
     """Return the closest possible equivalent to a 'home' directory.

     We first try $HOME.  Absent that, on NT it's $HOMEDRIVE\$HOMEPATH.

     Currently only Posix and NT are implemented, a HomeDirError 
exception is
     raised for all other OSes. """ #'

     try:
         return os.environ['HOME']
     except KeyError:
         if os.name == 'posix':
             raise HomeDirError,'undefined $HOME, IPython can not proceed.'
         elif os.name == 'nt':
             # For some strange reason, win9x returns 'nt' for os.name.
             try:
                 return 
os.path.join(os.environ['HOMEDRIVE'],os.environ['HOMEPATH'])
             except:
                 try:
                     # Use the registry to get the 'My Documents' folder.
                     import _winreg as wreg
                     key = wreg.OpenKey(wreg.HKEY_CURRENT_USER,
 
"Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders")
                     homedir = wreg.QueryValueEx(key,'Personal')[0]
                     key.Close()
                     return homedir
                 except:
                     return 'C:\\'
         elif os.name == 'dos':
             # Desperate, may do absurd things in classic MacOS. May 
work under DOS.
             return 'C:\\'
         else:
             raise HomeDirError,'support for your operating system not 
implemented.'

Cheers,

f

Fernando Perez wrote:

> It may be simpler than that:

So os.environ does change the environment under Python and its 
children.  The remaining question is what should TEXMFOUTPUT be?  
/home/user/.tex.cache will not work across all platforms.

Stephen Walton wrote:
> John Hunter wrote:
> 
> 
>>We might have to do something like
>>
>> os.popen('export TEXMFOUTPUT=/some/path; run some command')
>>
>>and then deal with platform and shell dependent differences in how to
>>set environment variables.  Is there a better way?  Me thinks it is
>>better to make this a FAQ and advise people working in non-writable
>>dirs to set this var themselves.
>>
> 
> I agree with this last.  On Unix, you could do
> 
> os.popen('/bin/sh -c "export TEXMFOUTPUT=/some/path; run some command"')
> 
> and be pretty sure it would work on all systems.  But Windows would be a 
> pain.  I agree with the FAQ solution.  This seems like a very rare 
> problem to me, to be honest.

It may be simpler than that:

planck[~/test]> cat env.py
#!/usr/bin/env python
import os

print 'before'
os.system('env | grep TEXMFOUTPUT')

os.environ['TEXMFOUTPUT'] = '/some/path'

print 'after'
os.system('env | grep TEXMFOUTPUT')
planck[~/test]> ./env.py
before
after
TEXMFOUTPUT=/some/path
planck[~/test]>

Cheers,

f

John Hunter wrote:

>We might have to do something like
>
>  os.popen('export TEXMFOUTPUT=/some/path; run some command')
>
>and then deal with platform and shell dependent differences in how to
>set environment variables.  Is there a better way?  Me thinks it is
>better to make this a FAQ and advise people working in non-writable
>dirs to set this var themselves.
>
I agree with this last.  On Unix, you could do

os.popen('/bin/sh -c "export TEXMFOUTPUT=/some/path; run some command"')

and be pretty sure it would work on all systems.  But Windows would be a 
pain.  I agree with the FAQ solution.  This seems like a very rare 
problem to me, to be honest.

On Jun 21, 2005, at 1:09 PM, John Hunter wrote:

>     Fernando> I also just saw pylab crash when a user was trying to
>     Fernando> run with $PWD being something he didn't have write
>     Fernando> access to.  Are there any checks in the code to fall
>     Fernando> back to /tmp or something sensible if texmanager can't
>     Fernando> write the temp files it needs?  Sorry for not giving a
>     Fernando> traceback, but I only saw this on someone else's screen
>     Fernando> while helping them, and for some odd reason it's not
>     Fernando> happening on my box.
>
> This is probably failing on the tex/latex temporary files.  I spent
> some time initially trying to figure out how to get these to go into
> ~/.tex.cache but didn't succeed.  If anyone knows how to direct
> tex/latex to put the various *.aux, *.log, etc, files in a specified
> directory, pass it my way.

I get this when mpl complains about not being able to create a 
.ttffont.cache (or whatever it's called) file.  I'll submit a bug on 
the tracker later.

Cheers!
Andrew

>>>>> "Stephen" == Stephen Walton <ste...@cs...> writes:

    Stephen>        TEXMFOUTPUT Normally, TeX puts its output files in
    Stephen> the current directory.  If any output file cannot be
    Stephen> opened there, it tries to open it in the directory
    Stephen> specified in the environment variable TEXM- FOUTPUT.
    Stephen> There is no default value for that variable.  For
    Stephen> example, if you say tex paper and the current directory
    Stephen> is not writable, if TEXMFOUTPUT has the value /tmp, TeX
    Stephen> attempts to create /tmp/paper.log (and /tmp/paper.dvi, if
    Stephen> any output is produced.)

Hmm, that looks familiar -- I think I did come across that.  But this
will be a bit of a pain to set from matplotlib, since we are making
calls to os.popen.  We might have to do something like

  os.popen('export TEXMFOUTPUT=/some/path; run some command')

and then deal with platform and shell dependent differences in how to
set environment variables.  Is there a better way?  Me thinks it is
better to make this a FAQ and advise people working in non-writable
dirs to set this var themselves.

Thanks for the help...

JDH

John Hunter wrote:

>This is probably failing on the tex/latex temporary files.  I spent
>some time initially trying to figure out how to get these to go into
>~/.tex.cache but didn't succeed.  If anyone knows how to direct
>tex/latex to put the various *.aux, *.log, etc, files in a specified
>directory, pass it my way.
>  
>
 From "man tex" on FC3, the section on environment variables:

       TEXMFOUTPUT
              Normally,  TeX  puts its output files in the current 
directory.
              If any output file cannot be opened there, it tries to 
open  it
              in  the  directory  specified in the environment variable 
TEXM-
              FOUTPUT.  There is no default value  for  that  
variable.   For
              example,  if you say tex paper and the current directory 
is not
              writable, if TEXMFOUTPUT has the value /tmp,  TeX  
attempts  to
              create  /tmp/paper.log  (and  /tmp/paper.dvi,  if any 
output is
              produced.)

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
>     Fernando> This was in a long-running session with very large
>     Fernando> memory allocations, but it dawned on me that
>     Fernando> get_dvipng_version(self) should cache its return value.
>     Fernando> There's no point in forcing a popen() call every single
>     Fernando> time, is there?
> 
> It already does cache the version
> 
>     def get_dvipng_version(self):
>         if self.dvipngVersion is not None: return self.dvipngVersion
>         sin, sout = os.popen2('dvipng --version')
>         ...snip...
> 
> I think the reason it is failing in your case is that is each renderer
> creation creates a new TexManager instance.  The cache should be on a
> class basis and not on a per instance basis (slaps self on head).
> Moving
> 
>         self.dvipngVersion = None
> 
> to the class level and out of __init__ should suffice.  I made this
> change, and similar changes in texmanager and backend_agg, so that
> caching is shared between instances.  Update from CVS and let me know
> if everything still works :-)

swamped at the moment, but I'll let you know if I see problems when I 
get a chance.

>     Fernando> I also just saw pylab crash when a user was trying to
>     Fernando> run with $PWD being something he didn't have write
>     Fernando> access to.  Are there any checks in the code to fall
>     Fernando> back to /tmp or something sensible if texmanager can't
>     Fernando> write the temp files it needs?  Sorry for not giving a
>     Fernando> traceback, but I only saw this on someone else's screen
>     Fernando> while helping them, and for some odd reason it's not
>     Fernando> happening on my box.
> 
> This is probably failing on the tex/latex temporary files.  I spent
> some time initially trying to figure out how to get these to go into
> ~/.tex.cache but didn't succeed.  If anyone knows how to direct
> tex/latex to put the various *.aux, *.log, etc, files in a specified
> directory, pass it my way.

I don't really know, sorry.  My texpertise is pretty limited, as you know :)

Thanks for the fixes!

f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

    Fernando> This was in a long-running session with very large
    Fernando> memory allocations, but it dawned on me that
    Fernando> get_dvipng_version(self) should cache its return value.
    Fernando> There's no point in forcing a popen() call every single
    Fernando> time, is there?

It already does cache the version

    def get_dvipng_version(self):
        if self.dvipngVersion is not None: return self.dvipngVersion
        sin, sout = os.popen2('dvipng --version')
        ...snip...

I think the reason it is failing in your case is that is each renderer
creation creates a new TexManager instance.  The cache should be on a
class basis and not on a per instance basis (slaps self on head).
Moving

        self.dvipngVersion = None

to the class level and out of __init__ should suffice.  I made this
change, and similar changes in texmanager and backend_agg, so that
caching is shared between instances.  Update from CVS and let me know
if everything still works :-)

    Fernando> I also just saw pylab crash when a user was trying to
    Fernando> run with $PWD being something he didn't have write
    Fernando> access to.  Are there any checks in the code to fall
    Fernando> back to /tmp or something sensible if texmanager can't
    Fernando> write the temp files it needs?  Sorry for not giving a
    Fernando> traceback, but I only saw this on someone else's screen
    Fernando> while helping them, and for some odd reason it's not
    Fernando> happening on my box.

This is probably failing on the tex/latex temporary files.  I spent
some time initially trying to figure out how to get these to go into
~/.tex.cache but didn't succeed.  If anyone knows how to direct
tex/latex to put the various *.aux, *.log, etc, files in a specified
directory, pass it my way.

Thanks,
JDH

Hi all,

I just had this crash in mpl:

/usr/lib/python2.3/site-packages/matplotlib/texmanager.py in 
get_dvipng_version(self)
     299     def get_dvipng_version(self):
     300         if self.dvipngVersion is not None: return 
self.dvipngVersion
--> 301         sin, sout = os.popen2('dvipng --version')
     302         for line in sout.readlines():
     303             if line.startswith('dvipng '):

/usr/lib/python2.3/os.py in popen2(cmd, mode, bufsize)
     614         def popen2(cmd, mode="t", bufsize=-1):
     615             import popen2
--> 616             stdout, stdin = popen2.popen2(cmd, bufsize)
     617             return stdin, stdout
     618         __all__.append("popen2")

/usr/lib/python2.3/popen2.py in popen2(cmd, bufsize, mode)
     145         specified, it sets the buffer size for the I/O pipes. 
The file objects
     146         (child_stdout, child_stdin) are returned."""
--> 147         inst = Popen3(cmd, False, bufsize)
     148         return inst.fromchild, inst.tochild
     149

/usr/lib/python2.3/popen2.py in __init__(self, cmd, capturestderr, bufsize)
      40         if capturestderr:
      41             errout, errin = os.pipe()
---> 42         self.pid = os.fork()
      43         if self.pid == 0:
      44             # Child

OSError: [Errno 12] Cannot allocate memory


This was in a long-running session with very large memory allocations, 
but it dawned on me that get_dvipng_version(self) should cache its 
return value.  There's no point in forcing a popen() call every single 
time, is there?

I don't know the texmanager code, so I don't want to touch it myself. 
But if the idea is OK, a simple property tag is enough to cache:


In [3]: def cached():
    ...:     try:
    ...:         return cached.cachedvalue
    ...:     except AttributeError:
    ...:         cached.cachedvalue=42
    ...:         return cached.cachedvalue
    ...:

In [4]: cached()
Out[4]: 42

I also just saw pylab crash when a user was trying to run with $PWD 
being something he didn't have write access to.  Are there any checks in 
the code to fall back to /tmp or something sensible if texmanager can't 
write the temp files it needs?  Sorry for not giving a traceback, but I 
only saw this on someone else's screen while helping them, and for some 
odd reason it's not happening on my box.

Cheers,

f

I built matplotlib on linux from source using:

python setup.py build
python setup.py install --home=3D/home/tom

when I try to import=20


>>> import pylab
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/tom/lib/python/pylab.py", line 1, in ?
    from matplotlib.pylab import *
  File "/home/tom/lib/python/matplotlib/pylab.py", line 199, in ?
    import backends
  File "/home/tom/lib/python/matplotlib/backends/__init__.py", line 19, in =
?
    globals(),locals(),[backend_name])
  File "/home/tom/lib/python/matplotlib/backends/backend_gtkagg.py",
line 11, in ?
    from backend_gtk import gtk, FigureManagerGTK, FigureCanvasGTK,\
  File "/home/tom/lib/python/matplotlib/backends/backend_gtk.py", line 21, =
in ?
    from backend_gdk import RendererGDK
  File "/home/tom/lib/python/matplotlib/backends/backend_gdk.py", line 45, =
in ?
    from matplotlib._nc_backend_gdk import pixbuf_get_pixels_array
ImportError: No module named _nc_backend_gdk


When I look in the backends dir in
/home/tom/lib/python/matplotlib/backends i see the following files
which does not include the .so file for _nc_backend_gdk

__init__.py          backend_gdk.py        backend_qtagg.py
__init__.pyc         backend_gdk.pyc       backend_qtagg.pyc
_na_backend_agg.so   backend_gtk.py        backend_svg.py
_nc_backend_agg.so   backend_gtk.pyc       backend_svg.pyc
backend_agg.py       backend_gtkagg.py     backend_template.py
backend_agg.pyc      backend_gtkagg.pyc    backend_template.pyc
backend_agg2.py      backend_gtkcairo.py   backend_tkagg.py
backend_agg2.pyc     backend_gtkcairo.pyc  backend_tkagg.pyc
backend_cairo.py     backend_paint.py      backend_wx.py
backend_cairo.pyc    backend_paint.pyc     backend_wx.pyc
backend_fltkagg.py   backend_ps.py         backend_wxagg.py
backend_fltkagg.pyc  backend_ps.pyc        backend_wxagg.pyc
backend_gd.py        backend_qt.py         tkagg.py
backend_gd.pyc       backend_qt.pyc        tkagg.pyc

Is there something I am doing wrong?


-Tom

Hi,

Steve Chaplin <ste...@ya...> wrote:

> FigureCanvasSVG.print_figure() ignores the dpi argument and prints at a 
> fixed dpi of 72, why is that? I know PS has a native dpi of 72, but I 
> don't think that applies to SVG. SVG is scalable - its not limited
> to a single, fixed, pixel size.

I don't know the answer to your question but will address your comment
on PS. It is a fully scalable format. The elements in a PostScript file
are expressed in PostScript points, but that is nothing more than a
unit. That doesn't need to map to pixels. It just says that some element
that is described as 72 PostScript points long should take 1 inch once
printed (if you want to respect the size intended by the creator of the
PostScript file).

All this AFAIK, since I don't know the PostScript programming language.

BTW: PostScript point != point in general; for instance, in TeX, 1 point
     is 1/72.27 inch (therefore, a bit smaller than 1 PostScript point).

-- 
Florent

I noticed (using GTKAgg) that if I save a png and svg of the same Figure
the width, height of the output files do not agree.

FigureCanvasSVG.print_figure() ignores the dpi argument and prints at a 
fixed dpi of 72, why is that? I know PS has a native dpi of 72, but I 
don't think that applies to SVG. SVG is scalable - its not limited
to a single, fixed, pixel size.

Also the SVG files produces something like
<svg
   width="576.000000"
   height="432.000000" 
    ...
I think the width, height should be integers.

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> My understanding is, the frontend does all its calculations
    Steve> in floating point and never uses fig.get_width_height()
    Steve> because its always dealing width width, height in inches
    Steve> and dpi.

    Steve> 'grep' shows that fig.get_width_height() is not used by the
    Steve> frontend, its only ever used by the backends so it does not
    Steve> really belong in Figure it belongs it FigureCanvas.

    Steve> The value of width/height in inches * dpi does not need to
    Steve> be integers, but what about the ACTUAL width, height values
    Steve> that the backends produce?  The backends will either draw
    Steve> to the display with width, height in integer pixels, or
    Steve> create an output file png, ps, svg etc, which in most
    Steve> (all?) cases will have integer width, height.  Does it make
    Steve> sense having an output file 1200.8 x 900.6? What use is the
    Steve> fractional point/pixel?

Hi Steve,

I don't see any use cases where one would use the floating point
values, so if you want to make the changes you propose, go ahead.  Be
sure to note them in the CHANGELOG and in API_CHANGES.

Thanks,
JDH

John,
Attached is an updated QT backend (I started from a CVS sync yesterday).  I 
can send you diffs if you like.

The main driver is to fix the problem with the plot not being the requested 
size when drawn on the screen.  The toolbar was implemented as a dockable 
QToolbar whose location cannot be predicted until drawing time.  This 
caused the toolbar to overlay the plot so the result was always a plot that 
was slightly shorter in height than the requested amount.

The following changes were made:

1) Changed the toolbar to be a horizontal bar of push buttons instead of a 
QToolbar and updated the layout algorithms in the main window 
accordingly.  This eliminates the ability to drag and drop the toolbar and 
detach it from the window.

2) Updated the resize algorithm in the main window to show the correct size 
for the plot widget as requested.  This works almost correctly right 
now.  It looks to me like the final size of the widget is off by the border 
of the main window but I haven't figured out a way to get that information 
yet.  We could just add a small margin to the new size but that seems a 
little hacky.

3) Changed the x/y location label to be in the toolbar like the Tk backend 
instead of as a status line at the bottom of the widget.

4) Changed the toolbar pixmaps to use the ppm files instead of the png 
files.  I noticed that the Tk backend buttons looked much nicer and it uses 
the ppm files so I switched them.

Ted

John Hunter wrote:
>>>>>>"Charles" == Charles Moad <cm...@in...> writes:
> 
> 
>     Charles> 	I think the slider should update with the display if
>     Charles> the dragging is enabled, so the slider value stays in
>     Charles> sync.  The typical user will understand that things will
>     Charles> be a little sliggish when plotting insane data such as
>     Charles> you example.  I am wanting to create a simple text/value
>     Charles> entry field, but I noticed that the backends don't
>     Charles> support the delete key in events.  Are there issues
>     Charles> across platforms with this?  If not, I will probably add
>     Charles> this.
> 
> Yes, you should add the delete key.  I was hacking a little bit
> yesterday on text entry.  An alternative to creating a text widget is
> to simply require each backend to define a few gui dependent functions
> that we don't to get involved with (get_filename, get_text, etc..) and
> then connect these to a button.  The button could say something like

Since I can't really offer much help on this topic (outside of my field 
of expertise), I'd be glad to assist with the PR effort for the upcoming 
MDE release.  I know you guys will be quite busy with the code, so I can 
work on writing the release announcements.  A first draft for your 
consideration:

------------------------
MDE: the Matplotlib Desktop Environment

John D. Hunter and the Matplotlib team proudly announce the dawn of a 
new era in interactive graphical desktops: MDE,  the Matplotlib Desktop 
Environment, is coming!  Are you tired of the endless Qt/GTK, 
KDE/Gnome/OSX debates?  Cry no more!  MDE is here, to provide a fully 
anti-aliased destkop environment with run-time backend selection (Tk, 
GTK, WX, Qt, FLTK and even CocoaAgg are supported, so there is room for 
all).

The first (alpha) release of MDE will include full scientific plotting 
capabilities, a testament to the vision of the core team.  Secondary 
utilities like file managers, web browsers and a python-based Office 
Suite (MatPlotOffice -- in development at the MPL underground 
laboratories), will come later...

So stop using KDE/Gnome now, and join the MDE fun!  You haven't really 
experienced modern computing until you've used MDE...
------------------------

I know it's a bit hyperbolic, but isn't that what a PR release is 
supposed to do?  Besides, we want the KDE and Gnome teams to take notice 
of the new kid on the block ASAP, so we better be loud from day one.

;-)

Cheers,

f

>>>>> "Charles" == Charles Moad <cm...@in...> writes:

    Charles> 	I think the slider should update with the display if
    Charles> the dragging is enabled, so the slider value stays in
    Charles> sync.  The typical user will understand that things will
    Charles> be a little sliggish when plotting insane data such as
    Charles> you example.  I am wanting to create a simple text/value
    Charles> entry field, but I noticed that the backends don't
    Charles> support the delete key in events.  Are there issues
    Charles> across platforms with this?  If not, I will probably add
    Charles> this.

Yes, you should add the delete key.  I was hacking a little bit
yesterday on text entry.  An alternative to creating a text widget is
to simply require each backend to define a few gui dependent functions
that we don't to get involved with (get_filename, get_text, etc..) and
then connect these to a button.  The button could say something like


 --------------------
|  xlabel: volts(s) |
 --------------------


and when you click on it calls get_text from the backend and updates
"volts(s)" with the text you supply (and in this example would update
the xlabel too).

Below is a buggy and incomplete example of using the region/cache/copy
stuff I mentioned before to type into an axes.  As before, it is
gtkagg only at this point.  In particular, the cursor is pretty
crappy.  Note I am using "None" which is what backspace currently
defines, to indicate the backspace key.  One thing that would make
this work better is to predefine the region the text goes into (an
Axes presumably) and just blit the entire axes bbox before
re-rendering the string with each character.  This would solve the
cursor erase on backspace bug you will notice if you try it.

This was just screwing around and not meant for public consumption,
but since you brought it up :-)

Anyone want to write a word processor in matplotlib <wink>?


## Example text entry ##

from pylab import *
from matplotlib.transforms import lbwh_to_bbox, identity_transform


class TextBox:
    def __init__(self, canvas, s='Type: '):
        self.canvas = canvas
        self.text = text(0.5, 0.5, s)
        draw()
        canvas.mpl_connect('key_press_event', self.keypress)        
        self.region = canvas.copy_from_bbox(self.get_padded_box())
        l,b,r,t = self.get_cursor_position()
        self.cursor, = plot([r,r], [b,t])

        
    def keypress(self, event):
        if event.key is not None and len(event.key)>1: return

        t = self.text.get_text()
        if event.key is None: # simulate backspace
            if len(t): newt = t[:-1]
            else: newt = ''
        else:            
            newt = t + event.key
            
        oldbox = self.get_padded_box()
        self.text.set_text(newt)
        newbox = self.get_padded_box()

        l,b,r,t = self.get_cursor_position()
        self.cursor.set_xdata([r,r])
        self.cursor.set_ydata([b,t])
        
        canvas = self.canvas
        canvas.restore_region(self.region)
        self.region = canvas.copy_from_bbox(newbox)
        f.draw_artist(self.text)
        f.draw_artist(self.cursor)                    
        canvas.blit(oldbox)
        canvas.blit(newbox)
        
    def get_padded_box(self, pad=5):
        l,b,w,h = self.text.get_window_extent().get_bounds()
        return lbwh_to_bbox(l-pad, b-pad, w+2*pad, h+2*pad)


    def get_cursor_position(self):
        l,b,w,h = self.text.get_window_extent().get_bounds()
        r = l+w+5
        t = b+h
        l,b = self.text.get_transform().inverse_xy_tup((l,b))
        r,t = self.text.get_transform().inverse_xy_tup((r,t))
        return l,b,r,t
        

        
ion()
f = figure()
title('Start typing')
axis([0, 2, 0, 1])    
box = TextBox(f.canvas)
axis([0, 2, 0, 1])    

show()

	I think the slider should update with the display if the dragging is
enabled, so the slider value stays in sync.  The typical user will
understand that things will be a little sliggish when plotting insane
data such as you example.
	I am wanting to create a simple text/value entry field, but I noticed
that the backends don't support the delete key in events.  Are there
issues across platforms with this?  If not, I will probably add this.

- Charlie

John Hunter wrote:
>>>>>>"Charles" == Charles Moad <cm...@in...> writes:
> 
> 
>     Charles> 	draw_idle still seems to suffer from the "trying to
>     Charles> catch up" problem.  I added the
>     Charles> gdk.POINTER_MOTION_HINT_MASK to enable passive mouse
>     Charles> motion event handling.  The gtk interface does not lag
>     Charles> behind with this enabled, even with complex figures.
>     Charles> Does this break functionality you are expecting somewhere
>     Charles> else?  Now the gtk backend acts the same as wx and tk
>     Charles> with respect to mouse motion.  Here is the reference I
>     Charles> found for addressing this problem:
>     Charles> http://www.pygtk.org/pygtk2tutorial/sec-EventHandling.html#id3096656
> 
> 
> On my system, the performance is acceptable with this somewhat
> pathological test case
> 
> from pylab import *
> 
> for i in range(1,7):
>     subplot(3,2,i)
>     imshow(rand(1000,1000), interpolation='bicubic')
> show()
> 
> So I'm happy to keep it.
> 
> Nice work.  Steve Chaplin, btw, is the resident gtk expert, so he may
> weigh in on the gtk strategy...
> 
> JDH

>>>>> "Charles" == Charles Moad <cm...@in...> writes:

    Charles> 	draw_idle still seems to suffer from the "trying to
    Charles> catch up" problem.  I added the
    Charles> gdk.POINTER_MOTION_HINT_MASK to enable passive mouse
    Charles> motion event handling.  The gtk interface does not lag
    Charles> behind with this enabled, even with complex figures.
    Charles> Does this break functionality you are expecting somewhere
    Charles> else?  Now the gtk backend acts the same as wx and tk
    Charles> with respect to mouse motion.  Here is the reference I
    Charles> found for addressing this problem:
    Charles> http://www.pygtk.org/pygtk2tutorial/sec-EventHandling.html#id3096656


On my system, the performance is acceptable with this somewhat
pathological test case

from pylab import *

for i in range(1,7):
    subplot(3,2,i)
    imshow(rand(1000,1000), interpolation='bicubic')
show()

So I'm happy to keep it.

Nice work.  Steve Chaplin, btw, is the resident gtk expert, so he may
weigh in on the gtk strategy...

JDH

	draw_idle still seems to suffer from the "trying to catch up" problem.
 I added the gdk.POINTER_MOTION_HINT_MASK to enable passive mouse motion
event handling.  The gtk interface does not lag behind with this
enabled, even with complex figures.  Does this break functionality you
are expecting somewhere else?  Now the gtk backend acts the same as wx
and tk with respect to mouse motion.
	Here is the reference I found for addressing this problem:
http://www.pygtk.org/pygtk2tutorial/sec-EventHandling.html#id3096656

- Charlie

John Hunter wrote:
>>>>>>"Charles" == Charles Moad <cm...@in...> writes:
> 
> 
>     Charles> 	I just committed code which adds a new kwarg to the
>     Charles> slider to allow for live updates while dragging.  It is
>     Charles> off by default since the gtk backend seems to queue
>     Charles> events.  Wx and tk work in a natural way (they don't
>     Charles> generate mouse events while busy).  Who is the resident
>     Charles> gtk expert, and do you think you know how to fix this?
>     Charles> It would be nice to have the live slider be on by
>     Charles> default.
> 
> The backend_bases.FigureCanvas defines a base method draw_idle which 
> calls draw by default
> 
>     def draw_idle(self, *args, **kwargs):
>         """
>         draw only if idle; defaults to draw but backends can overrride
>         """
>         self.draw(*args, **kwargs)
> 
> 
> backend_gtk subclasses this method to do proper idle drawing.  So call
> idle_draw from Slider.
> 
> Note that there are two updates to consider, the update of the slider
> and the update of the figure it is manipulating.  There is no reason
> not to continuously update the slider once you have this idle business
> sorted out.  But you probably do want to continuously update the
> figure it is modifying in every case, because the figure could be very
> complicated to draw.  Instead, you might want to expose this live
> update property as a checkbox in the slider, since if the figure is
> expensive (see examples/widgets/check_buttons.py and note you will
> have to update from CVS because I just committed a patch to make check
> buttons work for single buttons)
> 
> I've been working on how to draw individual artists w/o updating the
> entire figure.  This is mostly working with a few bugs in gtkagg.
> Basically you have to manage the background region as a memory chunk
> and then reblit the background before redrawing the artist.  This was
> designed to make animations faster and to support better GUI widgets.
> 
> The first example below shows how to draw just a rectangle and move it
> around the screen w/o updating the entire figure.  The second example
> is more complex, and makes a rectangle widget which you can move
> around the canvas or resize using a standard click on edge drag
> operation.  In this one, you create new rectangles by pressing "n"
> (only works on gtkagg).  Only two methods are required to support this
> on other backends
> 
>   region = canvas.copy_from_bbox(bbox)
>   canvas.restore_region(region)
>   canvas.blit(bbox)
> 
> This is all highly experimental and subject to change, but it maybe
> something you want to incorporate into the slider for better realtime
> updating.  Note that you can easily add copy_from_bbox and
> restore_region to cocoaagg by simply forwarding the calls onto the agg
> renderer, as gtkagg does.  For the blit method, you have to figure out
> how to make cocoa blit a region -- shouldn't be too hard.
> 
> JDH
> 
> ######## Example 1  #############
> 
> from pylab import *
> ion()
> ax = subplot(111)
> plot(rand(100), rand(100), 'o')
> 
> r = Rectangle((.5, .5), width=.1, height=.1)
> ax.add_patch(r)
> r.region = ax.figure.canvas.copy_from_bbox(r.get_window_extent())
> draw()
> def move(event):
>     if not move.idle or event.inaxes != ax: return
>     move.idle = 0
>     ax.figure.canvas.restore_region(r.region)
>     r.xy = event.xdata, event.ydata
>     r.region = ax.figure.canvas.copy_from_bbox(r.get_window_extent())
>     ax.draw_artist(r)
>     ax.figure.canvas.blit(ax.bbox)
>     move.idle = 1
> move.idle = 1
> connect('motion_notify_event', move)
> show()
> 
> 
> 
> ######## Example 2  #############
> from pylab import *
> from matplotlib.transforms import lbwh_to_bbox
> from matplotlib.mlab import dist_point_to_segment
> 
> class RectangleWidget(Rectangle):
>     def __init__(self, figure, *args, **kwargs):
>         Rectangle.__init__(self, *args, **kwargs)
>         self.figure = figure
>         self.idle = True
>         self.oldbox = self.get_window_extent()
>         self.newbox = self.get_window_extent()
>         
>         self.region = self.figure.canvas.copy_from_bbox(self.oldbox)
>         self.figure.canvas.mpl_connect('motion_notify_event', self.move)
>         self.figure.canvas.mpl_connect('button_press_event', self.press)
>         self.figure.canvas.mpl_connect('button_release_event', self.release)        
>         
>         self.figure.draw_artist(self)            
>         self._resize = False
>         self._drag = False
> 
>     def redraw(self):
>         canvas = self.figure.canvas
>         canvas.restore_region(self.region)
>         self.region = canvas.copy_from_bbox(self.newbox)
>         self.figure.draw_artist(self)            
>         canvas.blit(self.oldbox)
>         canvas.blit(self.newbox)
>         
>     def press(self, event):
>         if event.button!=1: return
>         x, y = self.xy
>         w, h = self.width, self.height
>         # the four line segments of the rectangle
>         lb = x, y
>         lt = x, y+h
>         rb = x+w, y
>         rt = x+w, y+h
>         segments = {
>             'left'   : (lb, lt),
>             'right'  : (rb, rt),
>             'top'    : (lt, rt),
>             'bottom' : (lb, rb),
>             }
>         p = event.x, event.y
>         near = []
>         for name, segment in segments.items():
>             s0, s1 = segment
>             d = dist_point_to_segment(p, s0, s1)
>             if d<5: near.append(name)
> 
>         info = event.x, event.y, self.xy[0], self.xy[1], self.width, self.height, near
>         if len(near):
>             self._resize = info
>             self.set_edgecolor('red')
>             self.set_linewidth(2)
>         else:
>             self._resize = False
>             if self.get_window_extent().contains(event.x, event.y):
>                 self._drag = info
>         self.redraw()
> 
>     def release(self, event):
>         if event.button!=1: return
>         self._resize = False
>         self._drag = False
>         self.idle = True
>         self.set_edgecolor('black')
>         self.set_linewidth(0.5)
>         self.redraw()
>         
>     def move(self, event):
>         if not (self.idle and (self._resize or self._drag)): return 
> 
>         self.idle = False
>         canvas = self.figure.canvas
>         if self._resize:
>             exo, eyo, xo, yo, wo, ho, near = self._resize
>         else:
>             exo, eyo, xo, yo, wo, ho, near = self._drag
> 
>         scalex=0; scaley=0; scalew=0; scaleh=0
>         if 'left' in near:
>             scalex = 1
>             scalew = -1
>         if 'right' in near:
>             scalew = 1
>         if 'bottom' in near:
>             scaley = 1
>             scaleh = -1
>         if 'top' in near:
>             scaleh = 1
> 
>         if self._drag:
>             scalex = 1
>             scaley = 1
>         
>         dx = event.x - exo
>         dy = event.y - eyo
>         if event.button ==1:
>             self.oldbox = self.get_padded_box()
> 
>             newx = xo + scalex*dx
>             if scalew==0 or newx<xo+wo:
>                 self.xy[0] = newx
>             newy = yo + scaley*dy
>             if scaleh==0 or newy<yo+ho:
>                 self.xy[1] = newy
> 
>             neww = wo + scalew*dx
>             if neww>0: self.width = neww
>             
>             newh = ho + scaleh*dy
>             if newh>0: self.height = newh
>             
>             #self.xy = event.x, event.y
>             self.newbox = self.get_padded_box()
>             #print event.x, event.y, self.get_padded_box().get_bounds()
>             self.redraw()
>         self.idle = True
> 
>     def get_padded_box(self, pad=5):
>         xmin = self.xy[0]-pad
>         ymin = self.xy[1]-pad
>         return lbwh_to_bbox(xmin, ymin, self.width+2*pad, self.height+2*pad)
>         
>         
>         
> ion()    
> fig = figure()
> #ax = subplot(111)
> 
> def keypress(event):
>     if event.key=='n':
>         widget = RectangleWidget( fig, (100,100), 20, 30)
>         fig.canvas.blit()
> 
> fig.canvas.mpl_connect('key_press_event', keypress)
> 
> show()
> 

>>>>> "Charles" == Charles Moad <cm...@in...> writes:

    Charles> 	I just committed code which adds a new kwarg to the
    Charles> slider to allow for live updates while dragging.  It is
    Charles> off by default since the gtk backend seems to queue
    Charles> events.  Wx and tk work in a natural way (they don't
    Charles> generate mouse events while busy).  Who is the resident
    Charles> gtk expert, and do you think you know how to fix this?
    Charles> It would be nice to have the live slider be on by
    Charles> default.

The backend_bases.FigureCanvas defines a base method draw_idle which 
calls draw by default

    def draw_idle(self, *args, **kwargs):
        """
        draw only if idle; defaults to draw but backends can overrride
        """
        self.draw(*args, **kwargs)


backend_gtk subclasses this method to do proper idle drawing.  So call
idle_draw from Slider.

Note that there are two updates to consider, the update of the slider
and the update of the figure it is manipulating.  There is no reason
not to continuously update the slider once you have this idle business
sorted out.  But you probably do want to continuously update the
figure it is modifying in every case, because the figure could be very
complicated to draw.  Instead, you might want to expose this live
update property as a checkbox in the slider, since if the figure is
expensive (see examples/widgets/check_buttons.py and note you will
have to update from CVS because I just committed a patch to make check
buttons work for single buttons)

I've been working on how to draw individual artists w/o updating the
entire figure.  This is mostly working with a few bugs in gtkagg.
Basically you have to manage the background region as a memory chunk
and then reblit the background before redrawing the artist.  This was
designed to make animations faster and to support better GUI widgets.

The first example below shows how to draw just a rectangle and move it
around the screen w/o updating the entire figure.  The second example
is more complex, and makes a rectangle widget which you can move
around the canvas or resize using a standard click on edge drag
operation.  In this one, you create new rectangles by pressing "n"
(only works on gtkagg).  Only two methods are required to support this
on other backends

  region = canvas.copy_from_bbox(bbox)
  canvas.restore_region(region)
  canvas.blit(bbox)

This is all highly experimental and subject to change, but it maybe
something you want to incorporate into the slider for better realtime
updating.  Note that you can easily add copy_from_bbox and
restore_region to cocoaagg by simply forwarding the calls onto the agg
renderer, as gtkagg does.  For the blit method, you have to figure out
how to make cocoa blit a region -- shouldn't be too hard.

JDH

######## Example 1  #############

from pylab import *
ion()
ax = subplot(111)
plot(rand(100), rand(100), 'o')

r = Rectangle((.5, .5), width=.1, height=.1)
ax.add_patch(r)
r.region = ax.figure.canvas.copy_from_bbox(r.get_window_extent())
draw()
def move(event):
    if not move.idle or event.inaxes != ax: return
    move.idle = 0
    ax.figure.canvas.restore_region(r.region)
    r.xy = event.xdata, event.ydata
    r.region = ax.figure.canvas.copy_from_bbox(r.get_window_extent())
    ax.draw_artist(r)
    ax.figure.canvas.blit(ax.bbox)
    move.idle = 1
move.idle = 1
connect('motion_notify_event', move)
show()



######## Example 2  #############
from pylab import *
from matplotlib.transforms import lbwh_to_bbox
from matplotlib.mlab import dist_point_to_segment

class RectangleWidget(Rectangle):
    def __init__(self, figure, *args, **kwargs):
        Rectangle.__init__(self, *args, **kwargs)
        self.figure = figure
        self.idle = True
        self.oldbox = self.get_window_extent()
        self.newbox = self.get_window_extent()
        
        self.region = self.figure.canvas.copy_from_bbox(self.oldbox)
        self.figure.canvas.mpl_connect('motion_notify_event', self.move)
        self.figure.canvas.mpl_connect('button_press_event', self.press)
        self.figure.canvas.mpl_connect('button_release_event', self.release)        
        
        self.figure.draw_artist(self)            
        self._resize = False
        self._drag = False

    def redraw(self):
        canvas = self.figure.canvas
        canvas.restore_region(self.region)
        self.region = canvas.copy_from_bbox(self.newbox)
        self.figure.draw_artist(self)            
        canvas.blit(self.oldbox)
        canvas.blit(self.newbox)
        
    def press(self, event):
        if event.button!=1: return
        x, y = self.xy
        w, h = self.width, self.height
        # the four line segments of the rectangle
        lb = x, y
        lt = x, y+h
        rb = x+w, y
        rt = x+w, y+h
        segments = {
            'left'   : (lb, lt),
            'right'  : (rb, rt),
            'top'    : (lt, rt),
            'bottom' : (lb, rb),
            }
        p = event.x, event.y
        near = []
        for name, segment in segments.items():
            s0, s1 = segment
            d = dist_point_to_segment(p, s0, s1)
            if d<5: near.append(name)

        info = event.x, event.y, self.xy[0], self.xy[1], self.width, self.height, near
        if len(near):
            self._resize = info
            self.set_edgecolor('red')
            self.set_linewidth(2)
        else:
            self._resize = False
            if self.get_window_extent().contains(event.x, event.y):
                self._drag = info
        self.redraw()

    def release(self, event):
        if event.button!=1: return
        self._resize = False
        self._drag = False
        self.idle = True
        self.set_edgecolor('black')
        self.set_linewidth(0.5)
        self.redraw()
        
    def move(self, event):
        if not (self.idle and (self._resize or self._drag)): return 

        self.idle = False
        canvas = self.figure.canvas
        if self._resize:
            exo, eyo, xo, yo, wo, ho, near = self._resize
        else:
            exo, eyo, xo, yo, wo, ho, near = self._drag

        scalex=0; scaley=0; scalew=0; scaleh=0
        if 'left' in near:
            scalex = 1
            scalew = -1
        if 'right' in near:
            scalew = 1
        if 'bottom' in near:
            scaley = 1
            scaleh = -1
        if 'top' in near:
            scaleh = 1

        if self._drag:
            scalex = 1
            scaley = 1
        
        dx = event.x - exo
        dy = event.y - eyo
        if event.button ==1:
            self.oldbox = self.get_padded_box()

            newx = xo + scalex*dx
            if scalew==0 or newx<xo+wo:
                self.xy[0] = newx
            newy = yo + scaley*dy
            if scaleh==0 or newy<yo+ho:
                self.xy[1] = newy

            neww = wo + scalew*dx
            if neww>0: self.width = neww
            
            newh = ho + scaleh*dy
            if newh>0: self.height = newh
            
            #self.xy = event.x, event.y
            self.newbox = self.get_padded_box()
            #print event.x, event.y, self.get_padded_box().get_bounds()
            self.redraw()
        self.idle = True

    def get_padded_box(self, pad=5):
        xmin = self.xy[0]-pad
        ymin = self.xy[1]-pad
        return lbwh_to_bbox(xmin, ymin, self.width+2*pad, self.height+2*pad)
        
        
        
ion()    
fig = figure()
#ax = subplot(111)

def keypress(event):
    if event.key=='n':
        widget = RectangleWidget( fig, (100,100), 20, 30)
        fig.canvas.blit()

fig.canvas.mpl_connect('key_press_event', keypress)

show()

I found a solution on google which required altering the gtk backend.
Live sliders are on by default now, so let me know if any backends
break.  Wx, Tk, and Gtk all seem to work for me.

Charles Moad wrote:
> 	I just committed code which adds a new kwarg to the slider to allow for
> live updates while dragging.  It is off by default since the gtk backend
> seems to queue events.  Wx and tk work in a natural way (they don't
> generate mouse events while busy).  Who is the resident gtk expert, and
> do you think you know how to fix this?  It would be nice to have the
> live slider be on by default.
> 
> - Charlie
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

	I just committed code which adds a new kwarg to the slider to allow for
live updates while dragging.  It is off by default since the gtk backend
seems to queue events.  Wx and tk work in a natural way (they don't
generate mouse events while busy).  Who is the resident gtk expert, and
do you think you know how to fix this?  It would be nice to have the
live slider be on by default.

- Charlie