To make mpv windows floating I use the following rule
for_window [title=".*mpv$"] floating enable
for_window [title="mpv"] floating and for_window [class="mpv"] floating did not work, but the one above does. In case it's important, vo is opengl, which works equally well under X11 and Wayland.
The problem is that the window's dimensions are not respected, resulting in a vertically stretched mpv window that looks like a tiled column but only floating.
Ping?
The issue is that the MPV dimensions are off?
mpv's window is always created with incorrect dimension, not the video's dimensions. It almost looks like sway intends to create it like a 2nd or 3rd vertically tiled window but the rule forces it to be floating. The way it's supposed to work is how a floating mpv is handled in dwm, spectrwm or xmonad.
It's even worse for Java Swing windows. Any (file) dialog you open will be very small. It's a little better in Weston.
_JAVA_AWT_WM_NONREPARENTING=1 is set.
XMonad suffers from this too as do dwm and spectrwm. WindowMaker and FVWM deal with Swing dialogs properly, and out of the X11 tiling WMs dwm and spectrwm behave a little better than XMonad.
Well if other WMs have that problem I can't see how it's our fault.
No, what I meant is that there's a similar issue which exists to varying degrees in other tiling window managers and also Weston (a floating compositor). That issue gets worse under Sway/XWayland, same as XWayland integration has more bugs in sway than it does in Weston/Xwayland. It is definitely a different bug, since none of the listed window managers or Weston exhibits the floating mpv problem.The Java issue doesn't need a floating rule or anything like that and is a quirk of Java Swing that's worse under Sway/XWayland.
So, it seems that sway creates the mpv window with dimensions like it was tiled as one of two or three columns, although it's floating.
The Java problem probably warrants a separate ticket.
Commenting on the Java problem: the windows are handled properly under the Awesome WM.
Some observations with today's build that's using https://github.com/Cloudef/wlc/commit/e3abf0b2f322b9d376ced452190cd4dd9f6fcb8a and https://github.com/SirCmpwn/sway/commit/ea0f1f3a7edf92537f74b70b520103bb38ff1411:
class="mpv" is useless anyway. So changing it to title="mpv" gives us a floating window that is correctly centered but where the dimensions are ignored or set so constraints as if it was tiled like a new column.i have the same issue too. i have this rule in ~/.config/sway/config
for_window [class="mpv"] floating enable, focus;
mpv window seems to be floating but with the same dimensions as if it were not floating, ie a vertically stretched mpv window that looks like a tiled column but only floating.
in my mpv.conf, i restrict mpv window size with autofit. so i can clearly see issues with window sizes.
this issue is not present in i3, nor in weston. so this seems to be sway specific.
testing further it seems mpv floating windows seem to take the same size as whatever they would be if not floating. if i do a $mod+v before mpv, floating window is a horizontal row across the middle of the screen. if i do a $mod+h before mpv, floating window is a vertical column across the middle of the screen. size is about the same as if it would have been, had it not been set to floating.
Closing due to wlroots rewrite.
Most helpful comment
It's even worse for Java Swing windows. Any (file) dialog you open will be very small. It's a little better in Weston.
_JAVA_AWT_WM_NONREPARENTING=1is set.XMonad suffers from this too as do dwm and spectrwm. WindowMaker and FVWM deal with Swing dialogs properly, and out of the X11 tiling WMs dwm and spectrwm behave a little better than XMonad.