matplotlib-users Mailing List for matplotlib

>>>>> "Frederic" == Frederic Back <fre...@gm...> writes:

    Frederic> On Thu, 2006-05-18 at 15:57 -0500, John Hunter wrote:
    >> You can comment out the code in backends/backend_gtk.py

    Frederic> Well, this seems like a bug to me, then. Matplotlib
    Frederic> offers the possibility to draw to a file instead of
    Frederic> opening a window. In this case, the default window icon
    Frederic> should *not* get overridden.

FYI, if all you are using matplotlib for is to write to a file, you
can just use the Agg backend (or PS or SVG or whatever) and GTK will
never be imported and the icon won't be touched.  

As an aside, if you are writing a GTK plugin you probably shouldn't be
using pylab at all, but rather the OO classes directly, as in
examples/embedding_in_gtk*.py.


    Frederic> The best way to patch this would be to set the default
    Frederic> window icon only when the gtk main loop is entered.

    Frederic> I attached a patch against the current SVN. It simply
    Frederic> moves the window icon declaration just before the line
    Frederic> where gtk.main() gets called.

I don't think this is the right place to put the patch -- "show" is
for pylab only, and it may be that application developers (me for one)
who won't be using pylab or calling show (they'll start the mainloop
themselves) and who like the icon for their mpl figures.  I agree that
always overriding the icon when import backend_gtk is a bit heavy
handed, though.  I hate to suggest another rc param, but we could have

gtk.icon :  matplotlib.svg  # use None to suppress the default
                            # minimization icon or an svg file to 
                            #  provide your own 

any better ideas?

JDH

On Thu, 2006-05-18 at 15:57 -0500, John Hunter wrote:
> You can comment out the code in backends/backend_gtk.py

Well, this seems like a bug to me, then. Matplotlib offers the
possibility to draw to a file instead of opening a window. In this case,
the default window icon should *not* get overridden.

The best way to patch this would be to set the default window icon only
when the gtk main loop is entered.

I attached a patch against the current SVN. It simply moves the window
icon declaration just before the line where gtk.main() gets called.

Should I file a bug somewhere? Or does the patch reach the devs here?

Thanks in advance,
Fred

>>>>> "Frederic" == Frederic Back <fre...@gm...> writes:

    Frederic> Hello, I'm developing a plugin in pygtk, which
    Frederic> indirectly (via networkx) uses matplotlib to display
    Frederic> graphs.

    Frederic> Now, I have the following problem: When I import pylab,
    Frederic> my window icon (the small icon in the window decoration)
    Frederic> gets replaced by the matplotlib icon. I pasted a sample
    Frederic> script below to illustrate.

    Frederic> This is amazingly annoying for me since I am merely
    Frederic> writing a plugin for an existing application and cannot
    Frederic> simply replace the original window icon.

    Frederic> Is there any way to supress this behaviour?

You can comment out the code in backends/backend_gtk.py

try:
    gtk.window_set_default_icon_from_file (
        os.path.join (matplotlib.rcParams['datapath'], 'matplotlib.svg'))
except:
    verbose.report('Could not load matplotlib icon: %s' % sys.exc_info()[1])


or physically remove the icon in which case you'll just get a report
that it is missing.  

You can also set the icon yourself after import matplotlib/backend_gtk
using the same code.

Hello,

I'm developing a plugin in pygtk, which indirectly (via networkx) uses
matplotlib to display graphs.

Now, I have the following problem: When I import pylab, my window icon
(the small icon in the window decoration) gets replaced by the
matplotlib icon. I pasted a sample script below to illustrate. 

This is amazingly annoying for me since I am merely writing a plugin for
an existing application and cannot simply replace the original window
icon.

Is there any way to supress this behaviour?

Please help me, and thanks in advance,
Fred


# ------------------------------------- sample code below
#!/usr/bin/python

import gtk
import pylab

w = gtk.Window()
b = gtk.Button("click me")
w.add(b)
w.show_all()

gtk.main()

>>>>> "Ryan" == Ryan Krauss <rya...@gm...> writes:

    Ryan> There is a serious flaw to my approach.  It seems that if
    Ryan> plot is called with an explicit linetype like 'b-', then
    Ryan> ax._get_lines.count is not automatically incremented.

You should never use an underscore variable since the leading
underscore basically indicates this is an internal variable and it
could be removed or changes at any point w/o documentation.  If
something changes in the "public" API, it will at least be documented
in the API_CHANGES file.

I think your best approach is to write some helper classes rather than
try and set the matplotlib defaults

  from mycyclers import colorcycler, linecycler

  for data in mydata:
     ax.plot(data, linestyle=linecycler(), color=colorcycler())

where linecycler and colorcycler are generators of some sort.  Rhen
you can alter your linecycler and colorcycler to do whatever you want,
make different defaults for color or grayscale, etc...

I'm not opposed to making the default linestyles and colorcycles
configurable, it has come up a few times, but it may be easier and
quicker for you just to code up some custom classes or functions that
have just the behavior you want.  

JDH

However, calling plot with color and linestyle keyword args instead of
'b-' in args leads to incrementing the line count, and things seem to
be working.  (I had actually written a little line count incrementing
function and then had to take it out when I wanted to specify rgb
values and switched to the kwargs).

Ryan

On 5/18/06, Ryan Krauss <rya...@gm...> wrote:
> There is a serious flaw to my approach.  It seems that if plot is
> called with an explicit linetype like 'b-', then ax._get_lines.count
> is not automatically incremented.
>
> Ryan
>
> On 5/18/06, Ryan Krauss <rya...@gm...> wrote:
> > Thanks Jouni.
> >
> > I can modify the color order using gca() and _getlines.colors, as you
> > mentioned.  But if I can't specify the line type in a similar fashion,
> > then this approach isn't going to work for me.
> >
> > The trick with the other approach (with a global counter for how many
> > lines are on the plot), is how to reset the counter for each new plot.
> >  gca()._get_lines.count seems to handle this problem by counting the
> > lines already on the axis.  (I wouldn't have known to poke around
> > there if you had got me started.)
> >
> > So, unless a cleaner approach is suggested by someone else, I am going
> > to follow an approach similar to Jouni's suggestion, only using
> > gca()._get_lines.count+1 as the index to my global colors and line
> > types list so that I am always calling plot (or actually semilogx)
> > with explicit linetype specifications (like 'y-','b--',...)
> >
> > Any better ideas?
> >
> > Ryan
> >
> > On 5/18/06, Jouni K Seppanen <jk...@ik...> wrote:
> > > "Ryan Krauss" <rya...@gm...> writes:
> > >
> > > > How do I change the default color order
> > >
> > > The colors are hardwired in the pylab interface, but you can hack
> > > around it:
> > >
> > >    gca()._get_lines.colors = ['#101050', '#105010', '#501010']
> > >    gca()._get_lines.Ncolors = 3
> > >    gca()._get_lines.firstColor = '#101050'
> > >
> > > Support for this might be a useful addition to the pylab interface.
> > > Does anyone know how to do this in Matlab?
> > >
> > > > and how do I set up a similar default linetype order, so that the
> > > > first call to plot generates a solid line and the second a dashed
> > > > one (for example).
> > >
> > > I don't think there is support for this in pylab.
> > >
> > > Of course, if all your plot calls just draw a single line, you can
> > > cycle both the color and the line style easily by defining your own
> > > function:
> > >
> > >    my_colors = ['b','g','r']; my_styles = ['-', ':', '--']
> > >    my_c = 0; my_s = 0
> > >    def plot(x, y):
> > >        global my_colors, my_styles, my_c, my_s
> > >        pylab.plot(x, y, my_colors[my_c % len(my_colors)]
> > >                         + my_styles[my_s % len(my_styles)])
> > >        my_c += 1; my_s += 1
> > >
> > > But if you want the full pylab.plot argument parsing functionality,
> > > the easiest thing would probably be to implement this in
> > > matplotlib.axis.
> > >
> > > --
> > > Jouni
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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 easier
> > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > > _______________________________________________
> > > Matplotlib-users mailing list
> > > Mat...@li...
> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> > >
> >
>

There is a serious flaw to my approach.  It seems that if plot is
called with an explicit linetype like 'b-', then ax._get_lines.count
is not automatically incremented.

Ryan

On 5/18/06, Ryan Krauss <rya...@gm...> wrote:
> Thanks Jouni.
>
> I can modify the color order using gca() and _getlines.colors, as you
> mentioned.  But if I can't specify the line type in a similar fashion,
> then this approach isn't going to work for me.
>
> The trick with the other approach (with a global counter for how many
> lines are on the plot), is how to reset the counter for each new plot.
>  gca()._get_lines.count seems to handle this problem by counting the
> lines already on the axis.  (I wouldn't have known to poke around
> there if you had got me started.)
>
> So, unless a cleaner approach is suggested by someone else, I am going
> to follow an approach similar to Jouni's suggestion, only using
> gca()._get_lines.count+1 as the index to my global colors and line
> types list so that I am always calling plot (or actually semilogx)
> with explicit linetype specifications (like 'y-','b--',...)
>
> Any better ideas?
>
> Ryan
>
> On 5/18/06, Jouni K Seppanen <jk...@ik...> wrote:
> > "Ryan Krauss" <rya...@gm...> writes:
> >
> > > How do I change the default color order
> >
> > The colors are hardwired in the pylab interface, but you can hack
> > around it:
> >
> >    gca()._get_lines.colors = ['#101050', '#105010', '#501010']
> >    gca()._get_lines.Ncolors = 3
> >    gca()._get_lines.firstColor = '#101050'
> >
> > Support for this might be a useful addition to the pylab interface.
> > Does anyone know how to do this in Matlab?
> >
> > > and how do I set up a similar default linetype order, so that the
> > > first call to plot generates a solid line and the second a dashed
> > > one (for example).
> >
> > I don't think there is support for this in pylab.
> >
> > Of course, if all your plot calls just draw a single line, you can
> > cycle both the color and the line style easily by defining your own
> > function:
> >
> >    my_colors = ['b','g','r']; my_styles = ['-', ':', '--']
> >    my_c = 0; my_s = 0
> >    def plot(x, y):
> >        global my_colors, my_styles, my_c, my_s
> >        pylab.plot(x, y, my_colors[my_c % len(my_colors)]
> >                         + my_styles[my_s % len(my_styles)])
> >        my_c += 1; my_s += 1
> >
> > But if you want the full pylab.plot argument parsing functionality,
> > the easiest thing would probably be to implement this in
> > matplotlib.axis.
> >
> > --
> > Jouni
> >
> >
> >
> > -------------------------------------------------------
> > 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 easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
>

Thanks Jouni.

I can modify the color order using gca() and _getlines.colors, as you
mentioned.  But if I can't specify the line type in a similar fashion,
then this approach isn't going to work for me.

The trick with the other approach (with a global counter for how many
lines are on the plot), is how to reset the counter for each new plot.
 gca()._get_lines.count seems to handle this problem by counting the
lines already on the axis.  (I wouldn't have known to poke around
there if you had got me started.)

So, unless a cleaner approach is suggested by someone else, I am going
to follow an approach similar to Jouni's suggestion, only using
gca()._get_lines.count+1 as the index to my global colors and line
types list so that I am always calling plot (or actually semilogx)
with explicit linetype specifications (like 'y-','b--',...)

Any better ideas?

Ryan

On 5/18/06, Jouni K Seppanen <jk...@ik...> wrote:
> "Ryan Krauss" <rya...@gm...> writes:
>
> > How do I change the default color order
>
> The colors are hardwired in the pylab interface, but you can hack
> around it:
>
>    gca()._get_lines.colors = ['#101050', '#105010', '#501010']
>    gca()._get_lines.Ncolors = 3
>    gca()._get_lines.firstColor = '#101050'
>
> Support for this might be a useful addition to the pylab interface.
> Does anyone know how to do this in Matlab?
>
> > and how do I set up a similar default linetype order, so that the
> > first call to plot generates a solid line and the second a dashed
> > one (for example).
>
> I don't think there is support for this in pylab.
>
> Of course, if all your plot calls just draw a single line, you can
> cycle both the color and the line style easily by defining your own
> function:
>
>    my_colors = ['b','g','r']; my_styles = ['-', ':', '--']
>    my_c = 0; my_s = 0
>    def plot(x, y):
>        global my_colors, my_styles, my_c, my_s
>        pylab.plot(x, y, my_colors[my_c % len(my_colors)]
>                         + my_styles[my_s % len(my_styles)])
>        my_c += 1; my_s += 1
>
> But if you want the full pylab.plot argument parsing functionality,
> the easiest thing would probably be to implement this in
> matplotlib.axis.
>
> --
> Jouni
>
>
>
> -------------------------------------------------------
> 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 easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

"Ryan Krauss" <rya...@gm...> writes:

> How do I change the default color order 

The colors are hardwired in the pylab interface, but you can hack
around it:

   gca()._get_lines.colors = ['#101050', '#105010', '#501010']
   gca()._get_lines.Ncolors = 3
   gca()._get_lines.firstColor = '#101050'

Support for this might be a useful addition to the pylab interface. 
Does anyone know how to do this in Matlab?

> and how do I set up a similar default linetype order, so that the
> first call to plot generates a solid line and the second a dashed
> one (for example).

I don't think there is support for this in pylab.

Of course, if all your plot calls just draw a single line, you can
cycle both the color and the line style easily by defining your own
function:

   my_colors = ['b','g','r']; my_styles = ['-', ':', '--']
   my_c = 0; my_s = 0
   def plot(x, y):
       global my_colors, my_styles, my_c, my_s
       pylab.plot(x, y, my_colors[my_c % len(my_colors)]
                        + my_styles[my_s % len(my_styles)])
       my_c += 1; my_s += 1

But if you want the full pylab.plot argument parsing functionality,
the easiest thing would probably be to implement this in
matplotlib.axis.

-- 
Jouni

Marcel,

It sounds like you want something like the attached example.  It works 
on my system based on svn and I expect it will work on a recent official 
release, but I haven't tried it.

Marcel Oliver wrote:
> Hi, I have a plot which is divided into 3x3 subplots, each of
> which is generated by imshow.  I now want to do the following
> and have difficulties finding the appropriate documentation:
> 
> 1. Display a single title for the entire plot.  title() will either
>    have no effect or attach the title to a separate subplot.
> 
> 2. Have the same color scale on each subplot.  Is it possible to
>    use automatic scaling?
> 
> 3. Attach a single colorbar to the entire plot, rather than
>    9 identical scales to each subplot.
> 
> 4. Have the labeling of the colorbar use the scientific
>    number format.  I sometimes have rather small values,
>    and colorbar() will display 0.0 throughout the scale.

This part depends on whether you are using svn, which as of this week 
has a new colorbar, or an earlier mpl release, with the original 
colorbar.  With either you can set the format string: for example, use 
tickfmt='%.2g' for the old colorbar or format='%.2g' for the new one. 
The new one should automatically choose a suitable format, but I see 
there is a problem with that.  I have to look into it.

Eric