New window does not replace the existing window #1
Comments
|
The ideal behavior is indeed to replace the window, but I haven't been able to figure out how to do it in all scenarios. Currently the program spawns the child command before hiding the terminal, which can lead to unpredictable behavior: In one case, the new window may open before the terminal is hidden. In this case the window will spawn as a child of the terminal, since the terminal is still the focused window at spawn. In the second case, the new window opens after the terminal is hidden. In this case the focused window will change to the other window group, since they are the only windows left. So when the new window spawns, it will spawn as a child to the other group, instead of being a child of the terminal itself. I guess the real solution to this would be to wait until the child window has spawned, before hiding the terminal. Or perhaps moving the new window to the same mark as the one set by the old window. Please let me know if I've got something wrong. I don't really know anything more about sway than I had to to write this program. Also, feel free to send a PR if you manage to make something that works better. I might find some time to personally look into this again, but cannot leave any deadlines. |
This is not at all ready to be merged, but is an experiment trying to implement rehanzo#1. By converting the original window into a split, the newly-created window is added to that split (which guarantees that they're adjacent). Since the original window is then hidden, the new window effectively takes its place. This has a few caveats: - There's a "wait 1s" hardcoded there: - If the new window is faster, this is weird and glitchy. - If the new window is slower, this doesn't work. - When the new window _exits_, the swallowed window won't always take its place: it'll be placed relative to the last-focused window, and I can't think of any way around this other than continuously monitoring the tree to find our right position. The timeout can we worked around by waiting for _any_ window to appear, and assuming the first new window to spawn is the one we're creating. This might be flaky, but I suspect it'd work 90% of the time. An alternative implementation could also be using a new stacked/tabbed layout, where the new window is a second in that container. If sway allowed us to hide the stack/tab bar on that container, we'd be 100% covered.
Say I have a vertical split like so:
If I run
swayhide somethingon my terminal, the terminal disappears, and thenew window appears as a child of the container on the right.
I kind of expected
swayhideto replace my current window with the new one,rather than spawn the new one elsewhere.
I think this can be achieved by:
The result is that the new window is dropped into the same place as the
original one, with affecting the exterior layout at all.
What are your thoughts on this? Does the idea/feature/change make sense?
The text was updated successfully, but these errors were encountered: