gtk3 toplevel windows incorrectly maximized under gnome3

[Roger Davis <rbd soest hawaii edu>]

Hi all,

I have been using several of my gtk3 apps on CentOS 6.x for a couple of 
years with no problem, but am now testing them under CentOS 7 (which uses 
gnome3's desktop, window manager, etc., instead of gnome2's) and have 
encountered a new difficulty with a window manager issue at app startup 
time. Some of these apps' toplevel windows are now consistently being 
initially and incorrectly displayed in a maximized state, meaning that 
they (together with their window-manager-attached titlebar) completely 
fill all available space on the gnome3 display between the top and bottom 
gnome-shell control (or whatever) bars. This happens every time these 
particular windows are first displayed. Other toplevel windows, however, 
never exhibit this problem despite the fact that they are being created by 
exactly the same code. All of my toplevels are explicitly size-initialized 
via the same calls to gtk_window_set_geometry_hints() and 
gtk_window_set_default_size(), setting the maximum size within the former 
equal to the default size of the latter.

After much experimentation I've determined that the problematic windows 
are all those which are close to, although not exceptionally close to, the 
display size. On an X11 display size of 1891x1110 pixels (this is within a 
VMWare Fusion VM), I can correctly initialize a 1763x900 window, for 
example, but not a 1763x901 or 1764x900 window. The limitations do not 
seem to be strictly about width or height, however, but rather about total 
area, as I can also correctly initialize a 1700x933 window but not a 
1701x933 or 1700x934 window. None of these sizes actually come within a 
couple dozen pixels of the edge of the usable display, so I have no idea 
why the window manager (if that is indeed the problem as I suspect) is 
deciding that it needs to maximize the window.

These windows all function as large image/plot areas consisting of a 
GtkDrawingArea (explicitly sized via gtk_widget_set_size_request() to the 
precise dimensions required by the app) within a GtkLayout within a 
GtkScrolledWindow within the toplevel window. I do not want the user to 
ever resize the toplevel to be larger than the GtkDrawingArea because it 
would expose undrawn pixels along the right and bottom edges, so the 
GtkDrawingArea size is passed to gtk_window_set_geometry_hints() as the 
maximum size. It's OK for the user to resize the toplevel window smaller 
than this size because of the available scrollbars, but in most cases the 
user will want the toplevel window to be exactly the same size as the 
drawing area so as to expose exactly the entirety of the latter and 
nothing more -- hence, I also pass the GtkDrawingArea size to 
gtk_window_set_default_size().

I have tried various things with gtk_window_set_geometry_hints() to try to 
give myself the maximum possible freedom when it comes to specifying a 
large and precise default window size, e.g.,

        geom.max_width= drawwidth;
        geom.max_height= drawheight;
        geom.width_inc= 1;
        geom.height_inc= 1;
        geom.min_aspect= 0.0001;
        geom.max_aspect= 10000.;
        gtk_window_set_geometry_hints(GTK_WINDOW(win), NULL, &geom, 
GDK_HINT_MAX_SIZE | GDK_HINT_RESIZE_INC | GDK_HINT_ASPECT);
        gtk_window_set_default_size(GTK_WINDOW(win), drawwidth, 
drawheight);

but nothing seems to help once drawwidth*drawheight begins to approach 
about 75% of the total screen area. The above code works perfectly well up 
to that point under CentOS 7, and has always worked at any size up to the 
full display size under CentOS 6 as well as MacOS/XQuartz.

How can I fix this?

Thanks!

Roger Davis
Univ. of Hawaii

PS: I'm not even sure where to look for info on gnome3 window manager (WM) 
bugs because I cannot figure out what WM is running under CentOS 7. 
Various web resources say it's mutter, but that's not in my system process 
list (although its RPM is installed), nor is anything else that looks like 
a WM (except perhaps gnome-shell itself). For whatever it's worth, I 
appear to be running in classic mode via 'gnome-session --session 
gnome-classic'. On systems where I do not have this problem, the running 
WMs are metacity (CentOS 6) and quartz-wm (MacOS/XQuartz). Information on 
this point of confusion would also be most welcome.

PPS: I have kludged a workaround with gtk_window_unmaximize() called from 
within a window-state-event signal handler, but would prefer to not use it 
as wrestling with a WM is nearly always a bad idea. 
gtk_window_unmaximize() does not seem to work for me if it is called 
before the window is mapped and a window-state-event signal is received.