summaryrefslogtreecommitdiffstats
path: root/DOCS
diff options
context:
space:
mode:
authorDudemanguy <random342@airmail.cc>2021-08-09 11:40:46 -0500
committerDudemanguy <random342@airmail.cc>2021-08-09 12:55:52 -0500
commit69c64f5fc4e7b8d9de8fdf2667643ccd759ec52f (patch)
tree51e9643deafcca4c5284ea9a24d1316df567f158 /DOCS
parent02323a184f2ddfed112d83d8e4f5880a0ee30480 (diff)
downloadmpv-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 'DOCS')
0 files changed, 0 insertions, 0 deletions