Wayland Pseudo-Client Side Decorations via OSC #7186
Conversation
|
The maximized fix is definitely good and something we should do correctly (it's part of xdg shell after all). I'm personally against CSDs in general (GNOME should just do things correctly imo), but I'm not going to die on a hill for it. If everyone else really wants it, then it's not a big deal to add. |
A compromise would be to make them so ugly that nobody in their right mind would think they are a good idea. Cyan text on a pink background using the cartooniest font one can find on the system, and make the window title "These decorations brought to you by GNOME". But maybe that's just being too petty. |
|
|
|
I mean, if someone went through the trouble of implementing this... |
|
The commit message subject lines ignore some of the cosmetic rules listed here: https://github.com/mpv-player/mpv/blob/master/DOCS/contribute.md#write-good-commit-messages |
|
I've repushed to fix the subject lines. I'll adapt to the new win_state functionality after it's pushed, but keep in mind my comment about minimize being write-only for Wayland. |
philipl
force-pushed
the
wayland
branch
2 times, most recently
from
07c6965 to
23fbc2a
Compare
|
I've updated the change set with minimize and maximize implemented as properties, by making the existing minimize property settable (although this now means that the VOs which report state cannot set it, and the VO that can set it can't report it. 🙄). I then added an equivalent maximized property, but it is only implemented on wayland here, of course. |
|
The subject line convention is still wrong and uses uppercase after :. Otherwise ok. |
Today, we support resizing wayland windows when we detect a touch event in a defined grab zone. As part of implementing pseudo-decorations, we should have equivalent functionality for mouse input. And if we detect support for actual decorations we will not activate the grab zone as the decorations will provide this.
|
I've updated the subject lines. I'm going to spend a bit more time tweaking the osc part to support left vs right placement and maybe have a pseudo-titlebar and then I'll push if there are no other concerns. |
|
LGTM |
Rather than hard-coding the edge grab zone width, we can make it user configurable. It seems worthwhile to have separate configs for pointer and touch usage as the defaults should be different, and a user might have both input methods in use.
At least with gnome-shell (I know, I know), the compositor does not provide the old window size when leaving the maximized state. Instead, we get a toplevel_config event with a 0x0 size and no additional states. Today, we already save the window geometry to restore it when leaving the fullscreen state, so we just need a small change for it to kick in for leaving the maximized state. If I read this correctly, we'll still respect the size passed by a compositor that actually provides the old size.
If we want to implement window pseudo-decorations via OSC, we need a way to tell the vo to minimize and maximize the window. Today, we have minimized as a read-only property, and no property for maximized. Let's made minimized settable and add a maximized property to go with it. In turn, that requires us to add VOCTRLs for minimizing or maximizing a window, and an additional WIN_STATE to indicate a maximized window.
We primarily care about pseudo-decorations for wayland, where the compositor may not support server-side decorations. So let's implement the minimize and maximize commands and return the maximized window state.
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.
|
@orbea File a separate issue with your full config. I can't trivially reproduce such a problem. |
|
@philipl No need anymore, one of the commits last night fixed it. :) |
|
what a cool idea @philipl to do it via https://mpv.io/manual/master/#on-screen-controller. |
|
You don't need to show the file title tho, it's redundant |
|
is there some command to change the mpv window buttons to the left or is still WIP? |
|
Yes. |
|
Thank you very much! |
I had previously mused about the possibility of doing CSDs on the cheap using OSC, so I dicided to just give it a go. It's a bit weird but it definitely works:
Along the way, I also fixed a wayland maximize bug and added support for triggering resize operations with a mouse.
This isn't exactly an RFC but it's also not fully complete. There's some control layout configs you'd probably want to add,and you might want to argue for implementing window control commands for other VOs (x11, win32, etc) although I think these controls have little to no value outside of Wayland.