# HG changeset patch # User Sam Lantinga # Date 1349292822 25200 # Node ID be103236441d503f9235ebecd701fb6412f13011 # Parent 44459e2f6e4d96ca89e7e5a2062dc1e3d362cf2f Poke window managers to get them to respect the resize hints. diff -r 44459e2f6e4d -r be103236441d src/video/x11/SDL_x11window.c --- a/src/video/x11/SDL_x11window.c Wed Oct 03 12:19:55 2012 -0700 +++ b/src/video/x11/SDL_x11window.c Wed Oct 03 12:33:42 2012 -0700 @@ -758,6 +758,36 @@ XSetWMNormalHints(display, data->xwindow, sizehints); XFree(sizehints); + + /* From Pierre-Loup: + For the windowed resize problem; WMs each have their little quirks with + that. When you change the size hints, they get a ConfigureNotify event + with the WM_NORMAL_SIZE_HINTS Atom. They all save the hints then, but + they don't all resize the window right away to enforce the new hints. + Those who do properly do it are: + + - XFWM + - metacity + - KWin + + These are great. Now, others are more problematic as you could observe + first hand. Compiz/Unity only falls into the code that does it on select + actions, such as window move, raise, map, etc. + + WindowMaker is even more difficult and will _only_ do it on map. + + Awesome only does it on user-initiated moves as far as I can tell. + + Your raise workaround only fixes compiz/Unity. With that all "modern" + window managers are covered. Trying to Hide/Show on windowed resize + (UnMap/Map) fixes both Unity and WindowMaker, but introduces subtle + problems with transitioning from Windowed to Fullscreen on Unity. Since + some window moves happen after the transitions to fullscreen, that forces + SDL to fall from windowed to fullscreen repeatedly and it sometimes leaves + itself in a state where the fullscreen window is slightly offset by what + used to be the window decoration titlebar. + */ + XRaiseWindow(display, data->xwindow); } else { XResizeWindow(display, data->xwindow, window->w, window->h); }