You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is somewhat of a frequent request to be able to put floating windows into the scrolling layout so that they scroll together with other windows. However, this doesn't really work well in general.
The floating window can easily get lost in the scrolling layout, e.g. end up outside to the right, beyond all other windows, making it unreachable. This could be somewhat fixed by clamping its position.
However, even then, the floating window will appear to randomly jump around the layout, since the window coordinates change abruptly. For example, closing a window to the left of the active window appears to preserve the active window's position, but actually it jumps the active window and all subsequent windows to the left.
This will be visible if there's a floating window inside the layout because it will just randomly jump around. You can observe it with a closing window animation if you make it slow enough, since it's a floating element inside the scrolling layout.
There's no longer an obvious/consistent way to navigate to the floating window with keyboard. If focus-column-left/right moves by columns, then how do you focus the floating window between the columns? How do you switch between that floating window and floating windows in the normal floating layout? How do you move windows between floating "inside" scrolling and floating "outside"?
Fortunately, there's a case that solves both 1 and 2: modal dialogs. They are most commonly used by GTK apps (only by GTK apps?), and only just recently a public Wayland protocol was merged that lets windows indicate the modal state: https://wayland.app/protocols/xdg-dialog-v1
Modal dialogs are dialogs (= has a parent window) that block input to the parent window.
They solve problem 1 by having a parent window. We can pin their position to that parent window in the scrolling layout.
They solve problem 2 by blocking input to the parent window. Which means that we can leave all keyboard navigation unchanged, and simply focus the dialog instead of the parent window when the parent window would get focus.
The way I envision this would work is similar to GNOME/Mutter: modal dialogs are always centered "over" their parent window, and you cannot separate the two. Though, it's still not entirely clear to me how some things will work from the niri side, e.g. what if the dialog goes bigger than the parent. I think in this case we can treat the dialog min size as the parent min size, and expand the column to accommodate it.
The text was updated successfully, but these errors were encountered:
It is somewhat of a frequent request to be able to put floating windows into the scrolling layout so that they scroll together with other windows. However, this doesn't really work well in general.
The floating window can easily get lost in the scrolling layout, e.g. end up outside to the right, beyond all other windows, making it unreachable. This could be somewhat fixed by clamping its position.
However, even then, the floating window will appear to randomly jump around the layout, since the window coordinates change abruptly. For example, closing a window to the left of the active window appears to preserve the active window's position, but actually it jumps the active window and all subsequent windows to the left.
This will be visible if there's a floating window inside the layout because it will just randomly jump around. You can observe it with a closing window animation if you make it slow enough, since it's a floating element inside the scrolling layout.
There's no longer an obvious/consistent way to navigate to the floating window with keyboard. If
focus-column-left/right
moves by columns, then how do you focus the floating window between the columns? How do you switch between that floating window and floating windows in the normal floating layout? How do you move windows between floating "inside" scrolling and floating "outside"?Fortunately, there's a case that solves both 1 and 2: modal dialogs. They are most commonly used by GTK apps (only by GTK apps?), and only just recently a public Wayland protocol was merged that lets windows indicate the modal state: https://wayland.app/protocols/xdg-dialog-v1
Modal dialogs are dialogs (= has a parent window) that block input to the parent window.
The way I envision this would work is similar to GNOME/Mutter: modal dialogs are always centered "over" their parent window, and you cannot separate the two. Though, it's still not entirely clear to me how some things will work from the niri side, e.g. what if the dialog goes bigger than the parent. I think in this case we can treat the dialog min size as the parent min size, and expand the column to accommodate it.
The text was updated successfully, but these errors were encountered: