diff options
author | Dudemanguy <random342@airmail.cc> | 2021-08-09 11:40:46 -0500 |
---|---|---|
committer | Dudemanguy <random342@airmail.cc> | 2021-08-09 12:55:52 -0500 |
commit | 69c64f5fc4e7b8d9de8fdf2667643ccd759ec52f (patch) | |
tree | 51e9643deafcca4c5284ea9a24d1316df567f158 /waftools/__init__.py | |
parent | 02323a184f2ddfed112d83d8e4f5880a0ee30480 (diff) | |
download | mpv-69c64f5fc4e7b8d9de8fdf2667643ccd759ec52f.tar.bz2 mpv-69c64f5fc4e7b8d9de8fdf2667643ccd759ec52f.tar.xz |
wayland: handle xdg-decoration protocol better
The current usage of the xdg-decoration protocol is quite a bit crude.
There's a specific listener struct for this like with most wayland
things, but mpv wasn't even using it. It also made no attempt to detect
if the compositor was telling mpv to use client side decorations. To
implement this correctly, first of all we need to create the decoration
listener object and add it like how most wayland things work. Secondly,
set_border_decorations needs to be changed to accept the uint32_t mode
given by the compositor. When we get the decoration event, pass the mode
obtained from the compositor to set_border_decorations. Update the mpv
border option, based on whether or not we have server side decorations
(yes if we have them; no if we don't). mpv can actually request either
client side or server side decorations with this protocol. This function
doesn't belong in set_border_decorations but rather it should be called
when the border option changes. Whether or not this request actually
works depends on the compositor (Plasma appears to allow it; sway does
not). If the compositor allows this request, then it gets handled by
configure_decorations. Note that the enum strangely starts at 1 hence
why there is an extra +1.
Diffstat (limited to 'waftools/__init__.py')
0 files changed, 0 insertions, 0 deletions