Cross-posting from StackOverflow.
I have a GTK3 application (
GtkApplication based) bound to a machinery on a touch screen without keyboard or mouse. In short that app should run in a locked maximized window: no other program must be shown. Not sure it is relevant but the window manager (that I need to show various dialogs) is xfwm4.
The problem is the user can drag or double click on the header and the window loses its original maximized status.
This is what I tried so far:
The obvious code: unfortunately the latter demaximizes the window.
It strips away the window header.
Ugly as hell and the latter shrinks the window to its original size.
Quite ugly but almost worked… it removes my application menu though.
Still hackish but… The user can still drag the window from the application menu though.
- Force the size request to the display size
Ugly: it effectively locks the window size but does not prevent the dragging of the window.
window-state-event by returning
It just seems to ignore my handler.
- Various combination of event masks/manipulations on the
No matter what I tried: the damned thing seems to don’t care.
Any chance to lock the window or to disable the resizing and repositioning behavior triggered by the window header?
I would use a fullscreen window for a kiosk-like application. You can pack a HeaderBar inside your window (e.g. as the first child of a vertical box) if you want one.
Yes, I will likely take this route. The problem is I’m using the application menu extensively and AFAIK it does not work on fullscreen windows.
I can rewrite it using a
GtkMenuButton but what bothers me is why locking a maximized window (that IMO should be a minor detail) has been proven so difficult to even require a substantial code change.
Because this is how window managers work.
There is no facility, either at the ICCCM or EWMH level, to describe a window that:
- can be maximized
- always sits at the top of the stack
- cannot be resized
At most, you can ask the window manager to respect various hints, or you can keep track of the monitor geometry and available workspace size, and resize your window accordingly. Of course, all of these policies are not necessarily implemented by every X11 window manager, or they may be implemented differently; that’s how X11 works—“mechanism, not policy”.
After many tests I can confirm the demaximization is likely done by the window manager. AFAIU from the EWMH specifications, the “resizability” of a window is not a native feature: a window can be made non-resizable only indirectly by settings the same minimum and maximum size in
WM_NORMAL_HINTS, i.e. effectively resizing the window.
My second request still stands though: it should be possible to disable the resizing and repositioning behavior. If I remember correctly (and I could be wrong) on GTK+2 era disabling the “configure” event on a toplevel GtkWindow was enough. Not sure why now this does not work anymore.
Apart from that I just followed @chrisaw suggestion (i.e. using a fullscreen window), so my curiosity is purely academic.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.