Instead of waiting for the surface to be mapped before sending a
configure event, do it on initial commit.
Note, wlroots 0.18 no longer sends automatic configure events on
initial commit.
- Update wlr_box includes to util/box.h: the wlroots header has
been moved upstream.
- Subsurface fields have been moved
- Create renderer and allocator, stop using wlr_backend_get_renderer
- Initalize output rendering
view.c:238:52: error: no member named 'subsurfaces' in 'struct wlr_surface'
wl_list_for_each (subsurface, &view->wlr_surface->subsurfaces, parent_link) {
~~~~~~~~~~~~~~~~~ ^
/usr/include/wayland-util.h:443:30: note: expanded from macro 'wl_list_for_each'
for (pos = wl_container_of((head)->next, pos, member); \
^~~~
/usr/include/wayland-util.h:409:32: note: expanded from macro 'wl_container_of'
(__typeof__(sample))((char *)(ptr) - \
^~~
Based on 3162766eef
xdg_shell.c:230:2: warning: implicit declaration of function 'wlr_xdg_surface_for_each_popup' is invalid in C99 [-Wimplicit-function-declaration]
wlr_xdg_surface_for_each_popup(xdg_shell_view->xdg_surface, iterator, data);
^
ld: error: undefined symbol: wlr_xdg_surface_for_each_popup
>>> referenced by xdg_shell.c:230 (../xdg_shell.c:230)
>>> cage.p/xdg_shell.c.o:(for_each_popup)
Based on 5438cc158a
* Don’t terminate display when no view is found
Some apps like RetroArch will quit and fork itself to switch
modes (like from the menu to a loaded core). This means that for a
very short period of time we have no view available for Wayland. Right
now, Cage doesn’t actually exit when it does this terminate, so you
get this kind of zombie child process that is running but not showing
anything on the screen because there is no compositor.
The solution I have here is to just keep Cage’s Wayland server running
to avoid this issue. I’m open to other idea, but this seems sane to
me. Perhaps an alternative is to check if the process is still alive
when this happens, if not then we can do the quitting behavior. In
addition, we could make this an option if some users don’t want this
behavior.
* Remove "ever_been_mapped" from cg_wayland_view
If the dialog extends the output layout in at least one dimension, then
the part of it that is larger than the output will be rendered
of-screen. This commit maximizes such dialogs instead.
Fixes#110.
This is based on code from Sway, which is also MIT licensed hence
compatible. This makes the surface damaging and rendering code easier to
follow and makes it easier to import future changes to Sway as well.
Outputs are arranged in a horizontal layout in the order they are
created in by wlroots. Maximized xdg_shell views will span all outputs,
like the global fullscreen mode in sway.
Fixes#87
The documentation for `wayland-server.h` says:
> Use of this header file is discouraged. Prefer including
> wayland-server-core.h instead, which does not include the server protocol
> header and as such only defines the library PI, excluding the deprecated API
> below.
See also
ca45f4490c (diff-b57e10fe0774258a6d21b22077001cff)
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.
This is the path we settled on in #24.
That is: any new toplevel window takes over the Cage display, hiding any
previous toplevels until it is closed. Only when the last toplevel is
closed, does Cage exit as well.
This allows us to check per-view whether is has dialogs open, instead of
diong it on a global basis as we are doing currently. This is necessary
for fully supporting multiple primary clients.
