Pin floating windows to tiled layer rather than output?

I have been trying to use scroll with DAWs recently, and my impression is that due to the way floating windows are currently handled, the UX of this is borderline unbearable even ignoring the Xwayland issues I described in #120.

At least with DAWs such as Ardour or Qtractor, floating windows generally get generated as transient/tool dialogs the main window, which is tiled; so the reasonable thing would be for their positioning to also be fixed relative to the tiled windows that generated them. Instead, however, they are positioned on a separate layer relative to the output, and so as you move left/right through the workspace, they "slide around" and occlude various parts of whatever you scroll to (which, under the intended setup of a single workspace containing related-but-distinct tiled windows, are things that are unrelated to the floating window).

Further injury is added to injury by the circumstance that when focussed, floating windows suppress the workspace motion keys (Super+Left,Right) completely. As a result, if I want to move through the workspace, half of the time movement is prevented because the cursor happened to be hovering some floating window; then I have to manually move the pointer into some region with no floating window in it, move along the workspace, and move enough floating windows out of the way to actually see the thing I moved over to. Then, half of the time, when I try to move back, I find that my mouse cursor wound up on top of a floating window again, blocking the backwards movement.

In my eyes, a more sensible approach would be for floating windows to be positioned as part of the infinite-scrolling workspace by default, and perhaps to introduce a distinct "pinned to workspace" state that corresponds to the current behaviour (and is distinguished from the current "pinned" state by not having the window appear on every workspace on the same output).

I am going to copy what I wrote in #120 to start the discussion:

scroll (and most tiling window managers) support floating windows, but they are not the main use case. There are two layers, tiling and floating. If you use both layers in your applications (some windows are tiled, some are floating), you will have those problems you mention. When you move focus to the tiling layer, trying to use keyboard focus will try to find another tiling window, ignoring floating windows. The same happens when you are in the floating layer, changing focus will take you to another floating window. Mouse focus ignores this restriction and can focus on any layer by moving the pointer over a window (focus_follows_mouse yes), or clicking on it (focus_follows_mouse no).

So my recommendation is when you want to use an application that uses a lot of small windows (like DAWs or GIMP), it is probably best to use them in FULL floating mode by using a window rule, for example for_window [app_id="gimp"] floating enable. scroll has a nice feature when you are using lots of floating windows, jump floating (defaults to $mod+alt+slash). This lets you see all the floating windows in a workspace in a view without overlap, and with a key press you can focus on any of them. This makes working with lots of floating windows and the keyboard much easier.

If you want to avoid having to deal with tiling and floating layers on one workspace, simply open your floating application in its own, dedicated workspace, so you won't need to use the layer focus command to recover focus when you accidentally click on a tiling window.

So, in essence, mixing floating and tiling windows for the same application is not a good idea unless it is just a short modal dialog that shows up floating and you need to interact with (file selection, OK/Cancel, etc.).

Well, isn't that's essentially saying that you can't benefit from the infinite-scroll paradigm at all when using floating windows? That means you start running into all the issues that are entailed by only having screen-sized workspaces - to begin with, for example, that you will need more of them if you routinely use a lot of programs at once.

In general, it seems to me that the present paradigm of handling floating windows was designed with "normal" tiling window managers in mind, which alone should be enough to warrant revisiting it for the infinite-scroll case. (Going beyond that, more controversially, it was designed for programs that do not heavily depend on floating windows at all. All of this has once again made me nostalgic for Win9x-style window-in-window MDI...)

If I were to implement the "floating, but pinned to tiling layer" behaviour I suggested, would you be willing to consider a PR?

edit: I found this issue discussing the same topic over at niri, and pointing out some potential pitfalls. I think that actually, a slight generalisation of the solution YaLTeR proposes might be useful and practical: pinning not just modal windows but any floating child windows to their tiled parent, and accordingly also clamping their position to that of the tiled parent (or at least demanding that they have nonzero intersection, that is, clamping the position to the tiled parent +- their own size).

Actually, there is no particular reason for it to be a parent either: just have it glued to any tiled (or non-tiled?) window, and eject into the floating layer if that window disappears. I remember compiz back in the days let you glue windows so children would keep their relative position to a parent, which was immensely useful for coping with old GIMP.

I'm struggling to grok the way by which workspace scrolling is handled and tracked right now (the arrange_* functions in sway/desktop/transaction.c?). Could you perhaps give me a quick rundown of the flow? (Like: What exactly happens when I press, say, Super+right on a workspace with many windows? At what point is it determined how far I need to scroll to focus the next client, how is the animation displayed, and where does the information about my current scroll offset wind up being stored?)

In the issue you mention, YaLTeR enumerates some of the pitfalls of such an approach, like for example you would pin a floating window to a tiled window that has nothing to do with the application that is floating, and it will be left out of the visible workspace. So his final proposal only talks about MODAL windows, which is what I mentioned above. Floating windows in a tiling window manager are usually for simple modal views, like a file selector or quick OK/Cancel window. Those are temporary windows, attached to a parent application, and that don't allow any other interaction with the application until they are closed. I mostly agree with him and have other reasons too.

As long as floating and tiling windows belong to different layers, any solution would have lots of problems, so either you merge them both, or it would not be very intuitive, with problems focusing and navigating.

Another issue if you merge both layers is with mouse focusing. Would moving the mouse to the edge of the monitor "scroll" to that side so you can access your floating windows that are not seen? That is something tiling window users will complain about, they don't like a mouse moving a bit too far to trigger scrolling. I know because I had to add several modes and special cases to avoid that.

So you basically want a virtual workspace for floating windows, but that would only work well when there are no tiling windows in that workspace.

The scrolling tiling paradigm in my opinion is basically useful to have combinations of windows at a useful resolution in nearby positions that allow visual interaction between them, but in most cases they are different applications (an editor and a browser, several terminals, etc.). When an application needs many windows open at the same time, tiling doesn't work very well, not even scrolling, and that is when floating is usually better. But then you want to be able to again see related windows at the same time, not have some of them in a part of the workspace that is not seen and you need to scroll to. That wouldn't be better than having them under the windows you are currently using. The advantage of scroll in those situations is you don't need to "search" for your hidden windows under a mountain of floating windows, moving them or clicking on some bar, you can use jump floating and all your windows will be shown without overlap.

So in general, I think floating windows and tiling windows should be kept separate. Applications should have all their windows in either tiling or floating mode, except for those short lived modal dialogs.

If you want to have some different solution to this problem, you will have to be more specific about the solution you would like, and address some of these problems in your proposal, simply pinning a floating window to a position in a virtual workspace wouldn't work for mixed workspaces. For example, I would understand some "special mode" for floating layers where there is an infinite canvas that you can scroll with the mouse (or keys from window to window) and create floating windows wherever you want, This would bring some practical problems too, but it is something I find more reasonable. One such problem is when you have two monitors, floating windows can move from one to the other freely because the canvas is limited, while if it was not, there would be no notion of reaching the end of the monitor.

I'm struggling to grok the way by which workspace scrolling is handled and tracked right now (the arrange_* functions in sway/desktop/transaction.c?). Could you perhaps give me a quick rundown of the flow? (Like: What exactly happens when I press, say, Super+right on a workspace with many windows? At what point is it determined how far I need to scroll to focus the next client, how is the animation displayed, and where does the information about my current scroll offset wind up being stored?)

sway rearranges windows every time there is a change, and it happens in arrange.c, because all the windows in a workspace are visible and they don't "move". But in scroll, a focus change may move the position of any other window, so rearranging happens after each transaction (transaction.c), like you discovered. Those arrange functions have to evaluate the new position for the focused container, so it complies with some restrictions, and then re-order all the other containers around it. It tries to do many things, like fitting several windows in the viewport, keeping pinned windows visible, working when there are trackpad gestures or animations...there is a lot going on there.

Sorry, I should have been more clear about the parenthetical remarks I kept piling on. So here's a very concrete proposal:

Introduce a new window state, "floating-relative".
Every floating-relative window has a unique parent window. If the parent is closed, the window reverts to "floating" state.
Every floating-relative window has a relative location. Assuming its size is (w,h) and the parent's size is (pw,ph), this location must be within [-w+1, pw+w-1], [-h+1, pw+h-1]. This invariant is maintained by clamping if w/h/pw/ph changes.
Every floating-relative window has a computed location, which is the sum of its relative location and the parent's computed location. This is the location it is rendered at.
For the purpose of computing tiled layout scroll offset, floating-relative windows are treated as occupying the bounding box of their parent (or rather, the earliest parent that is not a floating-relative window). Hence, no effort needs to be made to extend the scrollable area if they are partially off screen. The relative location constraint ensures they do not become "unreachable"/"lost".
(I'm not opinionated on this/open to better suggestions) For the purpose of keyboard focus, floating-relative windows are treated as part of their parent (earliest parent that is not a floating-relative window). Hence, it becomes possible to move around the infinite-scroll workspace without having to pay attention to them. However, the only way to give them focus (without introducing some new command) is the pointer.
To put a floating window into floating-relative state, create a new window move mode that, upon mouseup, "staples" the window to the highest other window under the pointer. Keyboard variants of this can be considered, e.g. staple to closest by focus stack.
This proposal lets you create arbitrarily deep trees of floating-relative parent-child relationships, but perhaps the UX would be simpler if one added the constraint that floating-relative windows can not have further floating-relative children.

In short, I am thinking of something akin to a promiscuous version of old-school MDI, where "child windows" are treated as window management dependents of a "parent window" at the price of being constrained to its area.

I was trying to find out if the sway/tree/container.c parent-child relationships could be easily adapted to support this, by making "floating-relative" windows actual children to their parent window in that data structure, the way client windows currently are handled as children to the layout containers.

Thank you for your detailed proposal.

Aside from the implementation and maintenance complexity of such an approach, into which I will not get right now, I don't see a clear benefit for it beyond having an infinite canvas also for floating windows.

You would still mix the tiling and floating layers, which will have the problems of having to switch layer focus to move from certain windows of an application (the tiled ones) to its floating counterparts. I still think each application should use only one of the two modes, -tiled or floating- for all its windows unless it is just a temporary, modal dialog that requires immediate attention and will be closed right after receiving it.
You are trying to solve the problem where all the floating windows have be be in the viewport. Why not tackle that problem without the complexity of keeping a window hierarchy and "locking", with different modes and bindings? For example, there could be a mode per workspace, something like floating infinite where when you are in floating focus mode, the mouse can scroll the FLOATING layout when hitting the monitor's edge. That way you would be able to extend the canvas and reposition your windows wherever you want (probably within certain practical limits), getting an "infinite" canvas without all the locking complexity of your proposal. Note all this would have to work horizontally and vertically too, which for the locking mechanism you favor would mean having to create fake windows so you can move your floating windows somewhere else. Instead, with the naïve infinite canvas you just scroll and set your windows wherever you want, which is a lot more intuitive and doesn't require new key bindings or triggering any action to lock etc..

I think you are basically thinking of how to optimize your DAW layout instead of looking at the whole floating/tiling paradigm. Locking, MDI etc. sound reasonable if you only care about one application, and want to mix tiling and floating for it. But in my opinion, as soon as you need several, permanent floating windows to manage an application (the DAW is a perfect example), you are better off setting them all floating, so you don't need to change focus mode all the time. Once you do that, having an infinite floating canvas could make sense to keep things tidy, I don't argue that, despite scroll having a jump floating mode to find things quickly.

The infinite canvas mode solution only affecting floating windows has an advantage: it leaves tiled windows in peace, the same as now tiled windows leave floating windows in peace. Tiling and floating layers continue working the same way, and you can enable/disable this mode per workspace. Focus works as it does now, you could use the keyboard or the mouse, without any new key bindings. jump floating would work the same way too, providing a scaled overview of your infinite floating canvas for quick movement.

I wasn't just thinking of DAWs, though they were the context in which this problem bothered me the most - having a floating tool window that I want to stick in a fixed place in the tiling layout is also useful when programming (monitor something while working in an IDE, etc.).

However, I do like the idea of an infinite-scroll floating layout too, and would not doubt use it if you implemented such a mode. I just didn't expect that you would be interested, given that you made a point to remove all the other tiling modes from sway when you made scroll. In fact, something like it has long been my dream idea of a window manager - all windows laid out on an infinite canvas, with every output treated not as a container but as a (movable) camera looking at a coordinate in this canvas, and workspaces replaced with bindable and rebindable locations to jump to with the current view. (Think RTS games, where apart from unit groups you often also get hotkeys to save/restore camera positions.)

The question with such a setup would be how to elegantly solve the placement of new windows, without having the setup either converge to a "pile" (mess of overlapping windows near the centre, thinning out towards the edge) or requiring constant manual repositioning ("cleaning your pile"). I thought that something like a "move and displace" action, which "pushes out" all windows covered by a selected one recursively, may work - in fact, in such a setting, the current behaviour of scroll could almost be emulated by constraining the pushing out to one axis.

Scroll has a problem, which is I added maybe too many features. The idea was to make many different workflows possible. Each user could use their own little subset of features and adapt it to fit an optimized workflow. But the end result is there are so many things (and key bindings!) you can do, many people feel overwhelmed, don't bother exploring the possibilities, and move on to something simpler.

The infinite floating canvas is not something I would use, but I could implement it, because it is not too hard to find a decent solution, and maybe some people would really like it.

I removed all the other layouts from sway because I wasn't going to use them, and they needed maintenance and made things harder, because they created a hierarchy of containers, while scroll has a simpler two level hierarchy. That allowed me several simplifications.

For things that we currently have and could overlap parts of what you would like to use, there are:

Sticky windows: always keep a reference window open no matter where you are
Scratchpad: temporarily open a reference window no matter where you are
Pinned tiled windows: always keep a tiled window "locked", no matter what's next to it.
Marks: go to any favorite window.
Trails and trailmarks: select paths of favorite windows and move among them easily, it even has its own overview mode, and using selections you can also move then somewhere else (gather and move).
Spaces: keep different window configurations for your workspace, including sizes and locations, recall them at will.

The infinite canvas with "marks" you describe is something that has been tried before in newm (video) and again something similar InifiniteGlass. They look like great ideas, but have a lot of practical problems. You end up spending a lot of time navigating, simply looking for things.

Classic tiling WMs always let you see everything, which makes finding things easier (no thinking, everything is visual), but they have the problem of having to resize things to make them usable.
Infinite WMs like newm let you have everything at the right size, but you spend a lot of time moving from one place to another, and even with the marks you propose (camera views), you need to remember them. This adds another step, things are no longer just visual, but you need to go to your RAM to remember a key to move where you want to. In the end it is the same as having workspaces, a workspace, a task.
Scrolling layouts are in-between, you can see things at their "correct" size (you skip the resizing step), but still need to go to your RAM to scroll to wherever you want to go. scroll uses jump to avoid having to remember a huge combination of "marks" (or camera views), it is always the same key that takes you to the visual step where you press the accelerator.

So no solution is perfect. I have tried many things and currently scroll is what I use. All those features I added were because I wanted to experiment with new workflows, and I have tried many.

Now, for the "infinite canvas"...

It would use mouse or keyboard to change focus and move around. Mouse would scroll the canvas when "pushing" the edges, and your new floating windows would be placed at the current location. When using the key bindings to change focus, things would work like they do now, quickly moving to the newly focused window. You would be able to use keys to scroll the canvas too, if you want. jump floating would still work, and get rid of the "pile" of overlapping windows if there would be any, as it does now. In fact, I don't need this infinite floating canvas because I use jump floating which is enough for me.

Forgive me if I'm necro-ing an old thread, but another good use case for pinning a window to a monitor would be for a picture-in-picture player. I usually have a video of some kind on a monitor, but I frequently swap between two workspaces. It would be nice if I could pin that singular window to the monitor so that it doesn't move. Otherwise I'd need to pivot to a "single workspace" setup and use spaces instead of workspaces.

You can already do that using sticky windows. Focus on a floating window, and call sticky toggle ($mod+Ctrl+Shift+a with the default config). The window will now show on all workspaces of the current monitor..

scroll has pin, which works for tiled workspaces, and pins a window so it is always visible within the workspace, regardless of what other window has focus (bu not if you change workspaces). And then sticky which comes from sway, and does what I described above, and I think you want.

This issue is about extending the layout for floating windows to use more space than the viweport.

Navigation Menu

Repository navigation

Pin floating windows to tiled layer rather than output? #123

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Pin floating windows to tiled layer rather than output? #123

Description

Activity

dawsers commented on Nov 4, 2025

blackhole89 commented on Nov 5, 2025

dawsers commented on Nov 5, 2025

blackhole89 commented on Nov 5, 2025

dawsers commented on Nov 7, 2025

blackhole89 commented on Nov 7, 2025

dawsers commented on Nov 7, 2025

eghere commented on May 22, 2026

dawsers commented on May 22, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions