From: Eric F. <ef...@ha...> - 2010-08-20 17:16:59
|
On 08/20/2010 05:24 AM, Benjamin Root wrote: > > > On Fri, Aug 20, 2010 at 10:12 AM, Ryan May <rm...@gm... > <mailto:rm...@gm...>> wrote: > > On Fri, Aug 20, 2010 at 9:41 AM, Benjamin Root <ben...@ou... > <mailto:ben...@ou...>> 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? 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 |