GTK still uses the (now deprecated) server-decoration protocol, which is
the predecessor to xdg-decoration. Hence, with this commit Cage now also
hides decorations on applications such as Firefox.
Fixes#47, see also
https://github.com/Hjdskes/cage/pull/45#issuecomment-466402865.
This commit adds a commandline switch (-d) to disable client side
decorations, if possible. In this case, Cage will not draw any
decorations of its own, in order to maximize screen real estate.
The default behavior remains the same, i.e., if -d is not passed,
clients will draw their client side decorations, if any.
Fixes#32
Cage uses wl_event_loop_add_signal to handle SIGINT and SIGTERM, which
masks these signals. This means that the subprocess spawned by Cage
start with these signals masked, which can lead to delays in Cage
shutting down on e.g. ^C. Hence, we now unmask all signals between fork
and exec.
Fixes#40
Override-redirect windows are meant to be ignored by the X server, at
least as far as position goes. Hence, we detect whether we're dealing
with such a window and consequently don't position it.
This makes, amongst others, Chromium's popup menus and dmenu appear on
the correct position and size.
Otherwise, we'll segfault:
0x00007ffff7c36715 in __strlen_avx2 () at /usr/lib/libc.so.6
0x000055555555ae00 in view_get_title (view=0x5555558403c0) at ../view.c:34
This was temporarily removed when introducing proper view abstractions.
Now that we have the cg_xwayland_view struct, we reintroduce this
workaround in its proper place.
This also fixes the previous workaround, which checked whether a view
was *currently* mapped and not if it *has ever* been mapped.
See #18, #19 and 443d955dfd.
When using the Wayland or X11 backend, Cage is drawn inside a window.
This commit sets this window's title to that of the currently focused
toplevel window inside Cage.
Fixes#29.
This is to work around "misbehaving" (for lack of a better term)
clients. At the moment, Firefox Nightly and Google Chrome/Chromium are
known to be suchs client:
When XWayland support is enabled, Firefox first creates an XWayland
surface, closes this (before mapping it) and then opens an XDG toplevel
surface. Cage tries to manage the first XWayland surface, but when it
closes, Cage has no surfaces left and hence closes as well.
Hence, Cage terminates before it picks up on Firefox's XDG toplevel, and
Firefox (rightly) prints it cannot read the Wayland pipe.
In Chromium's case, it simply opens an XWayland surface which it
immediately closes, before opening the "real" XWayland surface.
The workaround is to track whether an XWayland surface has been mapped
and, if it hasn't, to not exit when we have no views left.
Firefox's behavior and the workaround are discussed in #18.
This commit fixes#18 and is part of the fix for #19.
