Hi
I have one very nagging issue which I would like to solve with matplotlib once and for all: this may have to do with my desktop windown manager but I couldn't find much there, so any input is welcome.
When I open a new figure, the figure ALWAYS comes BELOW my current xterm (using KDE 4.3) and ALWAYS in the wrong place (top left corner where I usually put other windows). I would like some "smart" location for that figure so I don't have systematically to get it up and move it when I open a new figure. Is this linked to matplotlib? (this is the only application which is not managed properly in this context). I am using ipython -pylab as a working context (on opensuse 11.2).
thanks and cheers
Eric
Eric,
One possibility for this behavior might be that you might be defaulting to a different backend than QT. I would imagine if matplotlib is defaulting to the GTKAgg backend or the Tk backend, then the figure window would not behave properly in the window manager. You can set a default backend value to Qt4Agg in your matplotlibrc file. Maybe that would work.
Ben Root
···
On Fri, Aug 20, 2010 at 2:18 AM, Eric Emsellem <eemselle@…3246…> wrote:
Hi
I have one very nagging issue which I would like to solve with matplotlib once
and for all: this may have to do with my desktop windown manager but I couldn’t
find much there, so any input is welcome.
When I open a new figure, the figure ALWAYS comes BELOW my current xterm (using
KDE 4.3) and ALWAYS in the wrong place (top left corner where I usually put
other windows). I would like some “smart” location for that figure so I don’t
have systematically to get it up and move it when I open a new figure. Is this
linked to matplotlib? (this is the only application which is not managed
properly in this context). I am using ipython -pylab as a working context (on
opensuse 11.2).
thanks and cheers
Eric
I’ve had the same issue as Eric using Qt4Agg as the backend (and with all other backends I’ve used). As Eric mentioned, I have this windowing issue with ipython -pylab, but this issue also arises when running scripts from the command line and from my text editor (i.e. it’s not ipython specific).
-Tony
···
On Aug 20, 2010, at 10:41 AM, Benjamin Root wrote:
On Fri, Aug 20, 2010 at 2:18 AM, Eric Emsellem <eemselle@…513…> wrote:
Hi
I have one very nagging issue which I would like to solve with matplotlib once
and for all: this may have to do with my desktop windown manager but I couldn’t
find much there, so any input is welcome.
When I open a new figure, the figure ALWAYS comes BELOW my current xterm (using
KDE 4.3) and ALWAYS in the wrong place (top left corner where I usually put
other windows). I would like some “smart” location for that figure so I don’t
have systematically to get it up and move it when I open a new figure. Is this
linked to matplotlib? (this is the only application which is not managed
properly in this context). I am using ipython -pylab as a working context (on
opensuse 11.2).
thanks and cheers
Eric
Eric,
One possibility for this behavior might be that you might be defaulting to a different backend than QT. I would imagine if matplotlib is defaulting to the GTKAgg backend or the Tk backend, then the figure window would not behave properly in the window manager. You can set a default backend value to Qt4Agg in your matplotlibrc file. Maybe that would work.
Ben Root
Does it also happen with the QtAgg backend? Does the behavior change based on which backend you choose? That might help narrow down whether it is a problem with particular backends or with the backend interface.
Ben Root
···
On Fri, Aug 20, 2010 at 9:51 AM, Tony S Yu <tsyu80@…985…> wrote:
On Aug 20, 2010, at 10:41 AM, Benjamin Root wrote:
On Fri, Aug 20, 2010 at 2:18 AM, Eric Emsellem <eemselle@…513…> wrote:
Hi
I have one very nagging issue which I would like to solve with matplotlib once
and for all: this may have to do with my desktop windown manager but I couldn’t
find much there, so any input is welcome.
When I open a new figure, the figure ALWAYS comes BELOW my current xterm (using
KDE 4.3) and ALWAYS in the wrong place (top left corner where I usually put
other windows). I would like some “smart” location for that figure so I don’t
have systematically to get it up and move it when I open a new figure. Is this
linked to matplotlib? (this is the only application which is not managed
properly in this context). I am using ipython -pylab as a working context (on
opensuse 11.2).
thanks and cheers
Eric
Eric,
One possibility for this behavior might be that you might be defaulting to a different backend than QT. I would imagine if matplotlib is defaulting to the GTKAgg backend or the Tk backend, then the figure window would not behave properly in the window manager. You can set a default backend value to Qt4Agg in your matplotlibrc file. Maybe that would work.
Ben Root
I’ve had the same issue as Eric using Qt4Agg as the backend (and with all other backends I’ve used). As Eric mentioned, I have this windowing issue with ipython -pylab, but this issue also arises when running scripts from the command line and from my text editor (i.e. it’s not ipython specific).
-Tony
I can see the look of the widgets depending on the backend and current
desktop environment, but to a window manager, a window is a window.
They're all just X11 objects. The manager is just placing a box and
responding to minimize/maximze, etc.
It doesn't hurt to check, I just would be *GREATLY* surprised if
anything changed due to the window manager. My money would be on some
hint that a particular backend is failing to give the WM.
Ryan
···
On Fri, Aug 20, 2010 at 9:41 AM, Benjamin Root <ben.root@...1304...> wrote:
One possibility for this behavior might be that you might be defaulting to a
different backend than QT. I would imagine if matplotlib is defaulting to
the GTKAgg backend or the Tk backend, then the figure window would not
behave properly in the window manager. You can set a default backend value
to Qt4Agg in your matplotlibrc file. Maybe that would work.
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
One possibility for this behavior might be that you might be defaulting to a
different backend than QT. I would imagine if matplotlib is defaulting to
the GTKAgg backend or the Tk backend, then the figure window would not
behave properly in the window manager. You can set a default backend value
to Qt4Agg in your matplotlibrc file. Maybe that would work.
I can see the look of the widgets depending on the backend and current
desktop environment, but to a window manager, a window is a window.
They’re all just X11 objects. The manager is just placing a box and
responding to minimize/maximze, etc.
It doesn’t hurt to check, I just would be GREATLY surprised if
anything changed due to the window manager. My money would be on some
hint that a particular backend is failing to give the WM.
Ryan
That is exactly what I am thinking now that we know that it happens even with the Qt4Agg backend. Should these hints be given by the objects in backend_bases (for a consistent behavior), or do they have to be done by the individual backends? Maybe the hints could be stored as rcParams for all backends to refer to?
Ben Root
···
On Fri, Aug 20, 2010 at 10:12 AM, Ryan May <rmay31@…985…> wrote:
On Fri, Aug 20, 2010 at 9:41 AM, Benjamin Root <ben.root@…1304…> wrote:
–
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Hi
thanks a lot for the feedback.
Just tested with Qt4Agg and the window is coming up in the right location (just below my xterm where there is still space for a new window) now, and sometimes on TOP, but also sometimes at the BOTTOM.... I was using WxAgg before.
So it seems it is backend dependent at least with me (0.99). If this is confirmed I am ok for the moment to use Qt4Agg (if this does not impact other functionalities) as at least it seems to deal with the location in a better way. It would be better if really the link with the WM works better of course.
Eric
···
That is exactly what I am thinking now that we know that it happens even
with the Qt4Agg backend. Should these hints be given by the objects in
backend_bases (for a consistent behavior), or do they have to be done by
the individual backends? Maybe the hints could be stored as rcParams
for all backends to refer to
Every backend has a call to create a new toplevel window. All sorts of window properties, including window manager hints and requests, are controlled by some combination of the initializer and the methods of that toplevel window object, perhaps supplemented with toolkit-level functions and other methods of setting gui toolkit defaults. At present, I think mpl is simply using defaults for everything except the window dimensions. Certainly it would be possible to allow more customization, but it will require separate code for each gui backend. Putting in enough such code to provide some control over where windows are created, and whether they come up above or below existing windows, would be a nice project for someone, and would be a good enhancement to mpl. It would be good to agree on what the default behavior should be; the first step in such a project would be to make the defaults consistent among backends, to the extent permitted by the various toolkits and window managers.
Eric
···
On 08/20/2010 05:24 AM, Benjamin Root wrote:
On Fri, Aug 20, 2010 at 10:12 AM, Ryan May <rmay31@...287... > <mailto:rmay31@…287…>> wrote:
On Fri, Aug 20, 2010 at 9:41 AM, Benjamin Root <ben.root@...1304... > <mailto:ben.root@…1304…>> wrote:
> One possibility for this behavior might be that you might be
defaulting to a
> different backend than QT. I would imagine if matplotlib is
defaulting to
> the GTKAgg backend or the Tk backend, then the figure window
would not
> behave properly in the window manager. You can set a default
backend value
> to Qt4Agg in your matplotlibrc file. Maybe that would work.
I can see the look of the widgets depending on the backend and current
desktop environment, but to a window manager, a window is a window.
They're all just X11 objects. The manager is just placing a box and
responding to minimize/maximze, etc.
It doesn't hurt to check, I just would be *GREATLY* surprised if
anything changed due to the window manager. My money would be on some
hint that a particular backend is failing to give the WM.
Ryan
That is exactly what I am thinking now that we know that it happens even
with the Qt4Agg backend. Should these hints be given by the objects in
backend_bases (for a consistent behavior), or do they have to be done by
the individual backends? Maybe the hints could be stored as rcParams
for all backends to refer to?