diff options
author | Philip Langdale <philipl@overt.org> | 2019-11-26 08:50:14 +0800 |
---|---|---|
committer | Philip Langdale <github.philipl@overt.org> | 2019-11-29 16:56:20 +0800 |
commit | a220f086486563bf27110013fc3f2322bbb198c7 (patch) | |
tree | 44b0211f13718c7a274f1283a157115462beab7b /video/out/win_state.c | |
parent | 901b3dddb0c03d20ec634197b17a9d6b15e8e641 (diff) | |
download | mpv-a220f086486563bf27110013fc3f2322bbb198c7.tar.bz2 mpv-a220f086486563bf27110013fc3f2322bbb198c7.tar.xz |
osc: implement pseudo client side decorations via OSC
Today, if window decorations are not present, either because they were
disabled, or because the platform doesn't support them
(eg: gnome-shell on wayland), there are no window controls, meaning it
is not possible to minimize/maximize/close a window without knowing
keyboard shortcuts.
While you can imagine various ways of offering client side decorations,
it is attractive to consider using OSC because that is functionality
that we already have.
The main work here is defining a separate input area from the main
OSC box with its own buttons, etc.
While we could probably handle auto-detection based on whether
decorations are present or not, it's manually controlled for now.
The window control logic is mostly disconnected from the OSC itself,
except in the case of the `topbar` layout, where there has to be
coordination so that the controls don't get drawn on top of each other.
I had to do fine-positioning of the buttons based on the font on
my system, so don't be surprised if it looks wrong elsewhere.
You could also argue that window controls should be unscaled, even
if the main OSC box is scaled, but I've not tried to do this.
Diffstat (limited to 'video/out/win_state.c')
0 files changed, 0 insertions, 0 deletions