-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce move-global-* actions #963
base: develop
Are you sure you want to change the base?
Conversation
I just experienced some glitchy behavior where windows were offset from their intended spot. I'm not sure what I did to cause it, but I think registering the new keybinds via |
The differences here are relatively subtle. Without trying it out I can't say which one is the correct one to use. Or if you maybe even need a new one with slightly different options. The Regarding your other question about Also regarding the position of the window when you switch monitor. I believe the window will end up next to the focused window on that monitor. You probably want to move it to the end or start of the window list, depending on which direction the window comes from. I think there are existing functions for this, but not 100% if they can be used here. Maybe you need to add a new parameter to |
Added four new actions that swap windows, but move them across monitor boundaries if the focused window is the first/last window on the current monitor. These actions are supposed to complement the switch-global-* actions, and so the behavior is intended to be similar.
0250394
to
7cc424b
Compare
Alright, I think I'm on the right path now. I ended up passing the I went ahead and added two new functions to the Since Also, disregard what I said earlier about glitchy behaviour. I was being dumb and installed DashToPanel instead of DashToDock, and it was causing all sorts of problems. I switched to DashToDock and everything seems fine for now. The last thing I still have to do is moving the entire column of windows when switching monitors instead of just the focused window. I think I'll try to keep it simple and just reconstruct the column on the new monitor. I'm trying to think of a way to do this without creating another |
Nice work @glupi-borna, I'll try look at some of this. As for moving entire columns, the closet implementation we have is take/drop functionality: https://github.com/paperwm/PaperWM/blob/release/tiling.js#L5485-L5501 We're we have an array of metaWindows and change their space, and then call Moving a column (as is) to another space/monitor sounds like good functionality to add for sure. |
I added four new actions that swap windows, but move them across monitor boundaries if the focused window is the first/last window on the current monitor. These actions are supposed to complement the switch-global-* actions, and so the behavior is intended to be similar.
The implementation is simple: I used
swap(...)
when the window is not at the "edge" of the monitor, andswitchMonitor(...)
otherwise.There are some odd edge cases that I'd like to solve though, but I need a bit of guidance:
swap
), if the window is in a column, the whole column will move. However, when moving across monitors, becauseswitchMonitor
only moves the focused window, the rest of the stack is left behind on the first monitor.I'm sure that just calling
switchMonitor
is simply not the right thing to do here, and I should probably write a function that moves the whole column to the other monitor, but I'm not sure where to start with that. Should I simply move all of the windows in the column to the other monitor, and then callslurp
each of them in the right order? Are there other things I should be mindful of?