Sway: Floating rule does not respect mpv window dimensions

Created on 29 May 2016  路  12Comments  路  Source: swaywm/sway

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.

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=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.

All 12 comments

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:

Java Swing

  • Java Swing modal dialog initial dimensions seem to be respected correctly now.
  • General Wayland focus issue with Java Swing persists. Under Sway and Weston, if you have switched from the Swing window to another window and switch back, you have to explicitly set focus by clicking in the Swing window. Otherwise, Wayland doesn't give focus to the active window (Swing application) and none of the keys pressed are delivered to the Swing window.

mpv

  • mpv floating rule seems to be applied if mpv is an XWayland window and not using Wayland GPU context, but it's not centered. Since we want to use mpv's Wayland context to make use of the VAAPI pipeline, matching 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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dnkl picture dnkl  路  4Comments

RyanDwyer picture RyanDwyer  路  3Comments

emersion picture emersion  路  4Comments

StephenBrown2 picture StephenBrown2  路  4Comments

cauebs picture cauebs  路  3Comments