Re: [matplotlib-devel] problems with shared axis

[David Trem]

Hi,

 Eric, I will be happy to test your possible fix too. I have similar
problem with autoscaling shared axes like you Mark.

David

Mark Bakker a écrit :
> Thanks Eric.
> 
> You know that this has been on my wish list for a long time.
> 
> Let me know if I can test anything or help in any other way,
> 
> Mark
> 
> On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <[EMAIL PROTECTED]
> > wrote:
> 
> Mark Bakker wrote:
> 
> Hello list (especially Erik, who can fix this I hope) -
> 
> I have had problems with shared axes, especially when one of the
> axis has an aspect ratio that is set 'equal'. It has been
> discussed on the list before (mostly with Erik Firing), but it
> hasn't been fixed yet. What I want to do is have two plots. The
> top plot has an aspect ratio that is 'equal'. The idea is to
> have a contour plot in the top figure, while the bottom figure
> gives a cross-sectional picture of what I am plotting. This used
> to work well (quite some time ago), including zooming and such.
> But now I cannot plot it at all, let alone zoom.
> 
> My first problem is when I add a subplot with a shared x-axis,
> it changes the limits on the original x-axis. That seems to be a
> bug:
> ax1 = subplot(211)
> plot([1,2,3])  # Now the limits of the x-axis go from 0 to 2.
> subplot(212,sharex=ax1)  # Now the limits of both x-axis go from
> 0 to 1.
> 
> After all, the new subplot shares the axis with the existing
> subplot, so why doesn't it copy the axis limits from that subplot?
> 
> 
> I may have the fix for this, but I need more time to check and
> refine it--and try to make sure that I don't break anything else in
> the process.
> 
> 
> 
> But the bigger problem occurs when I want the aspect ratio of
> one of the first axis to be 'equal'.
> 
> ax1 = subplot(211,aspect='equal')
> plot([1,2,3]) subplot(212,sharex=ax1)
> 
> The second subplot is added, but the length of the graph is not
> the same as for the first subplot. It also resets the xlimits to
> go from 0 to 1, as before, which means the first subplot becomes
> unreadable (it still enforces 'equal' in the first subplot by
> changing the limits of the y-axis). When I now change the limits
> on the x-axis, the aspect ratio is not equal anymore
> 
> 
> I will see what I can do.  There are definitely some bugs that need
> to be squashed.
> 
> Eric
> 
> 
> ax1.set_xlim(0,2)
> draw()
> 
> Thanks for your help. I am willing to help in testing any changes.
> 
> Best regards, Mark
> 
> 
> 
> 
> 
> -
> 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
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] problems with shared axis

[David Trem]

Thank you very much Eric !

 It basically works for me but I think there is still a small bug
related to sharing y axes. I attach a small script that reproduce the
problem.
The end of the related error message is the following:

  File "*/lib/python2.5/site-packages/matplotlib/axes.py", line 515, in
__init__
if sharex._adjustable == 'box':
AttributeError: 'NoneType' object has no attribute '_adjustable'

Hope it could help.

David

Eric Firing a écrit :
> David Trem wrote:
>> Hi,
>>
>>  Eric, I will be happy to test your possible fix too. I have similar
>> problem with autoscaling shared axes like you Mark.
>>
>> David
> 
> I have committed to svn some changes to support autoscaling with shared
> axes, so please test.  I have done only very simple and cursory
> checking.  You might try reversed axes, log axes, etc.
> 
> I have not yet addressed the aspect ratio part of Mark's original post,
> below, but I think my changes have fixed the first of the two problems,
> in addition to adding autoscaling support, which I don't think we ever
> had before.
> 
> At present, autoscaling does not work with shared axes if an aspect
> ratio is specified.
> 
> Eric
> 
>>
>> Mark Bakker a écrit :
>>> Thanks Eric.
>>>
>>> You know that this has been on my wish list for a long time.
>>>
>>> Let me know if I can test anything or help in any other way,
>>>
>>> Mark
>>>
>>> On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <[EMAIL PROTECTED]
>>> <mailto:[EMAIL PROTECTED]>> wrote:
>>>
>>> Mark Bakker wrote:
>>>
>>> Hello list (especially Erik, who can fix this I hope) -
>>>
>>> I have had problems with shared axes, especially when one of the
>>> axis has an aspect ratio that is set 'equal'. It has been
>>> discussed on the list before (mostly with Erik Firing), but it
>>> hasn't been fixed yet. What I want to do is have two plots. The
>>> top plot has an aspect ratio that is 'equal'. The idea is to
>>> have a contour plot in the top figure, while the bottom figure
>>> gives a cross-sectional picture of what I am plotting. This used
>>> to work well (quite some time ago), including zooming and such.
>>> But now I cannot plot it at all, let alone zoom.
>>>
>>> My first problem is when I add a subplot with a shared x-axis,
>>> it changes the limits on the original x-axis. That seems to be a
>>> bug:
>>> ax1 = subplot(211)
>>> plot([1,2,3])  # Now the limits of the x-axis go from 0 to 2.
>>> subplot(212,sharex=ax1)  # Now the limits of both x-axis go from
>>> 0 to 1.
>>>
>>> After all, the new subplot shares the axis with the existing
>>> subplot, so why doesn't it copy the axis limits from that
>>> subplot?
>>>
>>>
>>> I may have the fix for this, but I need more time to check and
>>> refine it--and try to make sure that I don't break anything else in
>>> the process.
>>>
>>>
>>>
>>> But the bigger problem occurs when I want the aspect ratio of
>>> one of the first axis to be 'equal'.
>>>
>>> ax1 = subplot(211,aspect='equal')
>>> plot([1,2,3]) subplot(212,sharex=ax1)
>>>
>>> The second subplot is added, but the length of the graph is not
>>> the same as for the first subplot. It also resets the xlimits to
>>> go from 0 to 1, as before, which means the first subplot becomes
>>> unreadable (it still enforces 'equal' in the first subplot by
>>> changing the limits of the y-axis). When I now change the limits
>>> on the x-axis, the aspect ratio is not equal anymore
>>>
>>>
>>> I will see what I can do.  There are definitely some bugs that need
>>> to be squashed.
>>>
>>> Eric
>>>
>>>
>>> ax1.set_xlim(0,2)
>>> draw()
>>>
>>> Thanks for your help. I am willing to help in testing any
>>> changes.
>>>
>>> Best regards, Mark
>>>
>>>
>>>
>>> 
>>>
>>> -

Re: [matplotlib-devel] problems with shared axis

[David Trem]

Thanks Eric,

 It works perfectly for me now!
Actually, autoscale of shared axes simplify a lot
my own code so I'm really really pleased to see this functionality
is now directly integrated in matplotlib.
I'll do me best to test the svn version regularly.

Thanks again,

David

Eric Firing a écrit :
> David Trem wrote:
>> Thank you very much Eric !
>>
>>  It basically works for me but I think there is still a small bug
>> related to sharing y axes. I attach a small script that reproduce the
>> problem.
>> The end of the related error message is the following:
>>
>>   File "*/lib/python2.5/site-packages/matplotlib/axes.py", line 515, in
>> __init__
>> if sharex._adjustable == 'box':
>> AttributeError: 'NoneType' object has no attribute '_adjustable'
>>
>> Hope it could help.
> 
> It certainly does, thank you.  In a cut'n'paste operation, I had
> neglected to change a couple of 'x's to 'y's.  Fixed in svn.
> 
> Thanks again, and keep testing!
> 
> 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Problem with pan/ZOOM on semilog plot

[David Trem]

Hi,

 I've just discover a problem with the pan/zoom tool.
When using the pan/zoom tool (in the toolbar) on a semilogy plot the
zoom does not work correctly.
To visualize the problem launch the small script in attachment press the
pan/zoom button and use the zoom on the x axis direction -> you will see
the button part of the curve directly jumping at the bottom of the graph
  whereas you would expected it not to move...
I evidence this problem using GTKAgg but also with the OSX backend (did
not try other backend).
Matplotlib version is the latest svn on a MacOS X platform.

Thanks in advance,

David
import matplotlib
matplotlib.use('GTKAgg')
from pylab import *

t = arange(0.0, 2.0, 0.01)
s = exp(2*pi*t)
ax = semilogy(t, s, linewidth=1.0)
axis([-1.0, 3.0, 1e-3, 1e7])

xlabel('time (s)')
ylabel('voltage (mV)')
title('About as simple as it gets, folks')
grid(True)
show()
--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Problem with pan/ZOOM on semilog plot

[David Trem]

It works perfectly now using svn 6776

Thanks very much to be so efficient in killing bugs !
Less than three hours after my small bug report... I'm really impressed!

David

Eric Firing a écrit :
> John Hunter wrote:
>> On Sat, Jan 10, 2009 at 12:28 PM, David Trem 
>> wrote:
>>> Hi,
>>>
>>>  I've just discover a problem with the pan/zoom tool.
>>> When using the pan/zoom tool (in the toolbar) on a semilogy plot the
>>> zoom does not work correctly.
>>> To visualize the problem launch the small script in attachment press the
>>> pan/zoom button and use the zoom on the x axis direction -> you will see
>>> the button part of the curve directly jumping at the bottom of the graph
>>>  whereas you would expected it not to move...
>>> I evidence this problem using GTKAgg but also with the OSX backend (did
>>> not try other backend).
>>> Matplotlib version is the latest svn on a MacOS X platform.
>>
>> I don't think I see this -- if you hold down the 'x' while you are
>> panning, the zoom will be constrained in the x direction and I see no
>> unusual movement.  If I release the 'x' but still zoom horizontally,
>> there is some motion in the vertical direction, but that is because I
>> cannot move precisely horizontally.  Could you be more precise about
>> the artifact you are seeing. For me, the bottom part of the curve is
>> at (0, 10^0) and and I do not see any unusual behavior there
> 
> John,
> 
> I reproduced the problem (jumpy boundary with log scale and zoom) and
> fixed it in my last two commits (6773 to maint and 6775 merging to trunk).
> 
> Eric
> 
> 
>>
>> --
>>
>> Check out the new SourceForge.net Marketplace.
>> It is the best place to buy or sell services for
>> just about anything Open Source.
>> http://p.sf.net/sfu/Xq1LFB
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] zoom does not work properly when embedding with glade/gtk

[David Trem]

Hi,

 I do see strange behavior when using "Zoom to rectangle"
on my figures embedded in gtk through glade.
When clicking on the figure and start drawing the rectangle,
the bottom axis moves up as well as the graph which screw up
the whole figure during the rectangle definition. When releasing
the mouse button the figure looks ok.

I attach a small script together with glade file (slightly modified
from the matplotlib examples) that allows to reproduce the problem:
 -> launch the script, press the "Zoom to rectangle button" and start
drawing the rectangle region on the graph, you will see the issue...
It as to be noticed that pure gtk version (without glade) does work
properly.

I'm on MacOsX 10.5.8 using  gtk.gtk_version (2, 18, 6)
and gtk.pygtk_version (2, 16, 0) with python 2.6

Hope someone could help me solving this annoying issue.

Regards,

David
#!/usr/bin/env python
import matplotlib
matplotlib.use('GTK')

from matplotlib.figure import Figure
from matplotlib.axes import Subplot
from matplotlib.backends.backend_gtkagg import FigureCanvasGTKAgg as 
FigureCanvas
from matplotlib.backends.backend_gtkagg import NavigationToolbar2GTKAgg as 
NavigationToolbar
from matplotlib.widgets import SpanSelector

from numpy import arange, sin, pi
import gtk
import gtk.glade


def simple_msg(msg, parent=None, title=None):
dialog = gtk.MessageDialog(
parent = None,
type   = gtk.MESSAGE_INFO,
buttons= gtk.BUTTONS_OK,
message_format = msg)
if parent is not None:
dialog.set_transient_for(parent)
if title is not None:
dialog.set_title(title)
dialog.show()
dialog.run()
dialog.destroy()
return None



class GladeHandlers:
def on_buttonClickMe_clicked(event):
simple_msg('Nothing to say, really',
   parent=widgets['windowMain'],
   title='Thanks!')

class WidgetsWrapper:
def __init__(self):
self.widgets = gtk.glade.XML('mpl_with_glade.glade')
self.widgets.signal_autoconnect(GladeHandlers.__dict__)

self['windowMain'].connect('destroy', lambda x: gtk.main_quit())
self['windowMain'].move(10,10)
self.figure = Figure(figsize=(8,6), dpi=72)
self.axis = self.figure.add_subplot(111)

t = arange(0.0,3.0,0.01)
s = sin(2*pi*t)
self.axis.plot(t,s)
self.axis.set_xlabel('time (s)')
self.axis.set_ylabel('voltage')

self.canvas = FigureCanvas(self.figure) # a gtk.DrawingArea
self.canvas.show()
self.canvas.set_size_request(600, 400)
#self.canvas.set_events(
#gtk.gdk.BUTTON_PRESS_MASK  |
#gtk.gdk.KEY_PRESS_MASK  |
#gtk.gdk.KEY_RELEASE_MASK
#)
self.canvas.set_flags(gtk.HAS_FOCUS|gtk.CAN_FOCUS)
self.canvas.grab_focus()

def keypress(widget, event):
print 'key press'
def buttonpress(widget, event):
print 'button press'

#self.canvas.connect('key_press_event', keypress)
#self.canvas.connect('button_press_event', buttonpress)

def onselect(xmin, xmax):
print xmin, xmax

span = SpanSelector(self.axis, onselect, 'horizontal', useblit=False,
rectprops=dict(alpha=0.5, facecolor='red') )


self['vboxMain'].pack_start(self.canvas, True, True)
self['vboxMain'].show()

# below is optional if you want the navigation toolbar
self.navToolbar = NavigationToolbar(self.canvas, self['windowMain'])
self.navToolbar.lastDir = '/var/tmp/'
self['vboxMain'].pack_start(self.navToolbar)
self.navToolbar.show()

sep = gtk.HSeparator()
sep.show()
self['vboxMain'].pack_start(sep, True, True)


self['vboxMain'].reorder_child(self['buttonClickMe'],-1)





def __getitem__(self, key):
return self.widgets.get_widget(key)

widgets = WidgetsWrapper()
gtk.main()
 
http://glade.gnome.org/glade-2.0.dtd";>




  True
  window1
  GTK_WINDOW_TOPLEVEL
  GTK_WIN_POS_NONE
  False
  True
  False
  True
  False
  False
  GDK_WINDOW_TYPE_HINT_NORMAL
  GDK_GRAVITY_NORTH_WEST
  True
  
  
  

  

  4
  True
  False
  2

  
	
	  True

	  
	
	  True
	  _File
	  True

	  
		

		  
		
		  True
		  gtk-new
		  True
		  
		
		  

		  
		
		  True
		  gtk-open
		  True
		  
		
		  

		  
		
		  True
		  gtk-save
		  True
		  
		
		  

		  
		
		  True
		  gtk-save-as
		  True
		  
		
		  

		  
		
		  True
		
		  

		  
		
		  True
		  gtk-quit
		  True
		  
		
		  
		
	  
	
	  

	  
	
	  True
	  _Edit
	  True

	  
		

		  
		
		  True
		  gtk-cut
		  True
		  
		
		  

		  
		
		  True
		  gtk-copy
		  True
		  
	

[matplotlib-devel] Current svn version bug in get_xydata function in line.py

[David Trem]

Hi,

 There is a typo in the matplotlib line.py file in function get_xydata
line 662
it should be self._invalidx instead of self.invalidx
(missing leading underscore)

Regards,

David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] zoom does not work properly when embedding with glade/gtk

[David Trem]

Just for the records, the fix now applied to the svn and
discuss on this list under """Plot moves while using the "Zoom to
rectangle" button""" thread also fixes the problem I reported
earlier this year (see email below).

Best Regards,

David

Le 20/01/10 18:01, David Trem a écrit :
> Hi,
> 
>  I do see strange behavior when using "Zoom to rectangle"
> on my figures embedded in gtk through glade.
> When clicking on the figure and start drawing the rectangle,
> the bottom axis moves up as well as the graph which screw up
> the whole figure during the rectangle definition. When releasing
> the mouse button the figure looks ok.
> 
> I attach a small script together with glade file (slightly modified
> from the matplotlib examples) that allows to reproduce the problem:
>  -> launch the script, press the "Zoom to rectangle button" and start
> drawing the rectangle region on the graph, you will see the issue...
> It as to be noticed that pure gtk version (without glade) does work
> properly.
> 
> I'm on MacOsX 10.5.8 using  gtk.gtk_version (2, 18, 6)
> and gtk.pygtk_version (2, 16, 0) with python 2.6
> 
> Hope someone could help me solving this annoying issue.
> 
> Regards,
> 
> David

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] GTK pylab console

[David Trem]

Hi Nicolas,

  Your pycons is great!
I has to correct a small issue in the tar.gz from your website before 
being able to test pycons:
  I had to change:
"import gtk_console.console as cons"
to "import console as cons"
in pycons file around line 12.

After that I can report pycons is running on my MacBook (MacOS 10.5) 
with python, pygtk... from macports.

Another point:
do you mind releasing your code in a more permissive license that GPL. I 
mean LGPL or BSD like? I'm interested in including your code in my own 
LGPL app.

Thanks for this great peace of work.

All the best,

David

Nicolas Rougier a écrit :
> 
> Hi,
> 
> I've added some basic support for readline shortcuts:
> 
>  Ctrl-A: start of line
>  Ctrl-E: end of line
>  Ctrl-K: kill from cursor to end of line
>  Ctrl-Y: yank kill buffer
>  Ctrl-L: clear console
> 
> I've also added an option for displaying the toolbar(2).
> 
> Usage is now:
> 
> pycons [--ipython] [--pylab] [--toolbar]
> 
> 
> If the toolbar is not specified, commands can be typed directly within
> console: zoom(), pan(), home(), back(), forward(), save()
> 
> There is now a installable package (pycons.tgz) available from:
> 
> http://www.loria.fr/~rougier/pycons.html
> 
> 
> 
> Nicolas
> 
> 
> 
> On Mon, 2008-06-30 at 21:21 -0500, John Hunter wrote:
>> On Sun, Jun 29, 2008 at 9:28 AM, Nicolas Rougier
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> Thanks John, I've update the new version with your code.
>>>
>>> It is now available at:
>>>  http://www.loria.fr/~rougier/pylab.html
>>>
>>> You can now choose between python and ipython (option -s python
>>> or -s ipython) and all user events on a figure should be handled
>>> properly (mouse, scroll and key).
>>>
>>> Concerning the toolbar, is is quite easy to add but it is not
>>> very pleasant to the eyes. I'm looking for a more asethetic solution.
>> I've only had a limited chance to test this but it looks very
>> exciting.  I am amazed by how quickly you go the ipython shell
>> incorporated.  I am still a bit vexed by the lack of support for emacs
>> key bindings (I guess having ipython and readline support are not
>> enough, but I bet there is some gtk console code out there to support
>> them).  I do miss my CTRL-a and CTRL-k and friends.
>>
>> As for the toolbar, I think functionality over aesthetics carries the
>> day because it is easy to make it pretty after you make it work (and
>> you can always make it optional with a flag), but note that you do not
>> need to use the standard gtk toolbar widget -- you can write your own
>> that works however you want.  There is only minimal overhead for the
>> toolbar writer that is fairly well documented in backend_bases.py.
>> One option is to draw no toolbar at all but just  just set up key
>> bindings (press 'z' to toggle zoom mode, 'r' to toggle draw to rect
>> mode, etc, or draw your own toolbar or whatever.  But having the
>> functionality is a killer feature, in my opinion.
>>
>> Keep us posted.
>>
>> JDH
> 
> 
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] GTK pylab console

[David Trem]

Sorry for the trouble, I started testing your "old" pylab wich was 
provided without the setup script, which led me testing pycons from the 
pycons folder itself (no setup.py install done).
Pycons was actually working fine.
However, I encounter problem when closing the console with a graph 
inside and with the >>>help() command which is freezing the windows... 
But this is basically usable.

Thanks you very much considering my license request!
I don't think there could be license issue with matplotlib since it is 
also using a quite permissive license. Could the matplotlib gurus 
comment on that?

Thanks,

David

Nicolas Rougier a écrit :
> 
> Thanks,
> 
> I changed the license to a BSD one, hope this is compatible with
> matplotlib. I also changed the module name from 'gtk_console' to pycons
> since it makes more sense.
> 
> I also tried to remove the gtk_console.console (now this is
> pycons.console) in favor of console but it does not work as expected I
> would say. In fact, I'm surprised it's working for you. What do you get
> from a simple "import pycons" ?
> 
> Nicolas
> 
> 
> On Tue, 2008-07-01 at 14:32 +0200, David Trem wrote:
>> Hi Nicolas,
>>
>>   Your pycons is great!
>> I has to correct a small issue in the tar.gz from your website before 
>> being able to test pycons:
>>   I had to change:
>> "import gtk_console.console as cons"
>> to "import console as cons"
>> in pycons file around line 12.
>>
>> After that I can report pycons is running on my MacBook (MacOS 10.5) 
>> with python, pygtk... from macports.
>>
>> Another point:
>> do you mind releasing your code in a more permissive license that GPL. I 
>> mean LGPL or BSD like? I'm interested in including your code in my own 
>> LGPL app.
>>
>> Thanks for this great peace of work.
>>
>> All the best,
>>
>> David
>>
>> Nicolas Rougier a écrit :
>>> Hi,
>>>
>>> I've added some basic support for readline shortcuts:
>>>
>>>  Ctrl-A: start of line
>>>  Ctrl-E: end of line
>>>  Ctrl-K: kill from cursor to end of line
>>>  Ctrl-Y: yank kill buffer
>>>  Ctrl-L: clear console
>>>
>>> I've also added an option for displaying the toolbar(2).
>>>
>>> Usage is now:
>>>
>>> pycons [--ipython] [--pylab] [--toolbar]
>>>
>>>
>>> If the toolbar is not specified, commands can be typed directly within
>>> console: zoom(), pan(), home(), back(), forward(), save()
>>>
>>> There is now a installable package (pycons.tgz) available from:
>>>
>>> http://www.loria.fr/~rougier/pycons.html
>>>
>>>
>>>
>>> Nicolas
>>>
>>>
>>>
>>> On Mon, 2008-06-30 at 21:21 -0500, John Hunter wrote:
>>>> On Sun, Jun 29, 2008 at 9:28 AM, Nicolas Rougier
>>>> <[EMAIL PROTECTED]> wrote:
>>>>> Thanks John, I've update the new version with your code.
>>>>>
>>>>> It is now available at:
>>>>>  http://www.loria.fr/~rougier/pylab.html
>>>>>
>>>>> You can now choose between python and ipython (option -s python
>>>>> or -s ipython) and all user events on a figure should be handled
>>>>> properly (mouse, scroll and key).
>>>>>
>>>>> Concerning the toolbar, is is quite easy to add but it is not
>>>>> very pleasant to the eyes. I'm looking for a more asethetic solution.
>>>> I've only had a limited chance to test this but it looks very
>>>> exciting.  I am amazed by how quickly you go the ipython shell
>>>> incorporated.  I am still a bit vexed by the lack of support for emacs
>>>> key bindings (I guess having ipython and readline support are not
>>>> enough, but I bet there is some gtk console code out there to support
>>>> them).  I do miss my CTRL-a and CTRL-k and friends.
>>>>
>>>> As for the toolbar, I think functionality over aesthetics carries the
>>>> day because it is easy to make it pretty after you make it work (and
>>>> you can always make it optional with a flag), but note that you do not
>>>> need to use the standard gtk toolbar widget -- you can write your own
>>>> that works however you want.  There is only minimal overhead for the
>>>> toolbar writer that is fairly well documented in backend_bases.py.
>>>> One option is to draw no toolbar at a

[matplotlib-devel] "shared axes" bug in matplotlib 0.98

[David Trem]

Hi,

 I narrowed down the problem I've posted on the matplotlib user list
and now it looks like I found a matplotlib bug in 0.98 version.

The shared axes auto-scaling is not properly working in 0.98 (works
with the 0.91). Indeed, As shown, in the small attached script, the
shared x scale does not show the full curves (axs1 blue curve should go 
up to 120 on axis).
In fact, if x axes is shared, the figure xmin and xmax are defined by 
the last plotted axes (axs2) and does not take into account the min/max 
from the first one which cut it. One would expect to see both curve 
entirely.


Could someone have look at this problem. I will try to dive in 
matplotlib code but I'm not an expert at all...


Thanks in advance,

David
import matplotlib
matplotlib.use('gtkagg')

import pylab as pl

if __name__ == "__main__":

axs1 = pl.subplot(111)
t = pl.arange(0.01, 200.0, 0.01)
s1 = pl.log(t)
pl.plot(t, s1, 'b-')


axs2 = pl.gcf().add_axes(axs1.get_position(),
 sharex=axs1, frameon=False)
pl.plot([-20,30], [1,2], 'r-')

pl.show()
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] "shared axes" bug in matplotlib 0.98

[David Trem]

Thanks Michael and Eric for your constructive replies and your help.
It is know clear for me why my code was luckily working with 0.91 but 
not with 0.98. This is certainly going to help me finding a robust 
solution for both cases.

Regards,

David

Michael Droettboom a écrit :
> David,
> 
> There is no code in matplotlib to autoscale shared axes, and as far as I 
> know, there never has been.  Unfortunately, it's more or less a 
> requirement that you have to set the limits manually when using shared 
> axes.  (All of the shared axes examples do this).
> 
> I think, 0.91 is broken also, it just happens to use the first plotted 
> line rather than the second (it truncates the red line, rather than the 
> blue one).  The difference in ordering is due to the fact that sharing 
> is now always bi-directional in 0.98 and it uses dictionaries with a 
> somewhat random ordering, rather than lists.  If you see different 
> behavior than my plots (attached) let me know.
> Eric Firing wrote:
>> This looks like a rather fundamental problem in the present 
>> architecture.  I thought I had a solution figured out, but I was 
>> wrong, and now I am not confident that I can come up with a good 
>> solution quickly.  Some consultation with, or intervention by, Mike D. 
>> may be needed--he might even see a solution in a matter of minutes.  
>> The problem is that the dataLim for each axes object is a Bbox, and in 
>> this implementation there is no way to share an x-interval or a 
>> y-interval among Bboxes.  So there is a single xaxis major locator 
>> that is shared, but it is only getting its dataLim updated from one of 
>> the shared axes.
>>   
> 
> Just to clarify: this limitation is not new to the 0.98 architecture.  
> 0.91 also uses Bboxes for data limits and does not directly share the x- 
> or y-limits: they are updated using callbacks when the limits change.  
> The difference in 0.98 is that the references between axes are set up 
> (effectively) bidirectionally so there's no longer a notion of a 
> "controlling" axes and "following" axes.  It was easy in 0.91 to set up 
> a situation where shared axes would only update if one, but not both, of 
> the pair were zoomed/panned, and that bug has been fixed.
> 
> Back when the 0.98 transformations were being written, John and I had a 
> long discussion about whether data limits should be Bbox-like or 
> pair-of-intervals-like, and we ultimately decided to leave things as-is 
> to avoid creating too much newness at once.  IMHO, however, the real 
> problem is that the shared axes mechanism doesn't know whether the 
> limits are changing because of autoscaling (in which case the limits 
> should be unioned together), or panning/zooming, in which case the 
> limits need to be replaced.  The second problem is probably necessary to 
> fix whether we use Bboxes or not.
> 
> Cheers,
> Mike
> 
> 
> 
> 
> 
> 

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Alpha Weirdness on Windows

[David Trem]

Hi,

Just a remark:
   GTKAgg on win32 is a combination I also use every day.
And I think many people also use it.

GTK is the almost only (nice) toolkit providing straightaway the same 
look and feel independantly of the platform used. This is very important 
if you would like to deploy the same software on an heterogeneous 
environment and you don't want users to rediscover the same software on 
different platforms.
I personally prefer to use the "same" Gimp, whatever I'm in front of a 
Linux, Windows or Mac platform. And believe me or not, It happens almost 
everyday in my research environment where I have a Mac on my desk, 
windows platform controlling experiments, Unix stations running 
simulation softwares and a Linux when I come back home...

Sorry for hijacking this thread, I was I bit chocked by John statement 
and wanted to react.

All the best,

David


John Hunter a écrit :
> On Thu, Jul 17, 2008 at 10:35 PM, Ryan May <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Has anyone ever noticed weirdness with translucent polygons on win32
>> (using GTKAgg)?  I had the occasion to actually do something on windows
>> and noticed that, having drawn some polygons with alpha < 1, if I
>> resized the window or panned, the alpha channel seemed to disappear and
>> leave solid-colored polygons.
> 
> gtkagg on win32 is a very unusual combination -- one I used a lot in
> the day myself but it seems noone else did.  It is really hard to
> understand how something like this can happen from the way the code is
> written, but yes, if you can get any insight into it, we'd certainly
> like to understand and fix it.  I have at least one fairly significant
> piece of code that requires gtkagg on windows
> 
> For starters, just posting the output of a script run with
> --verbose-helpful so we can get some version info for the archives
> will be useful.
> 
> JDH
> 
> -
> 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
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel