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= 1.;
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.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
