Loop
Loop copied to clipboard
MrKai77
🐞 CTRL+PageUp/Down for switching screen not working
Bug Description
I use doubletap Ctrl as the trigger. Everything works EXCEPT Next/Previous Screen that I have mapped to CTRL+PageUp/PageDown. It can be mapped but doesn't actually do anything.
Steps To Reproduce
- map Trigger key to left CTRL (Doublepress)
- map Next Screen to Trigger+PageDown
- doublepress CTRL, press PageDown
- nothing will happen
Expected Behavior
Active windows to move to the next screen
Actual Behavior
Nothing happens
Screenshots
No response
MacOS Version
sonoma 14.4
Loop Version
Version 1.0.0-beta.14 (644)
Additional Context
No response
Final Checks
- [X] My issue title is descriptive
- [X] This is a single bug (multiple bugs should be reported individually)
Interesting, I don't have a keyboard with those buttons so I haven't been able to test them yet. I'll try remapping some keys to Page Up/Page Down on my computer to see if I can reproduce this issue :)
Loop is very confused with dual display setup.
A) Issue Nr. 1 - assign, say, trigger+[ to move a window to next window and trigger+] to move to previous window. The first move works (regardless if it's Next or Previous), the second doesn't. Meaning, you can move a window but can't move it back.
B) Issue Nr. 2 - Next and Prev screen command seems to be buggy, it combines the move with maximizing. If I have a regular, non-maximized window and use Next Screen command, it does move the window AND for some reason also maximizes it. That shouldn't be happening.
A) Issue Nr. 1
That's really weird... are both displays the same size? or is one bigger than the other?
B) Issue Nr. 2
Yeah.. if a window hasn't interacted with Loop yet, Loop defaults to maximizing the window on the new display. But now that I think about it, it might make more sense to simply center the window on the new display. Is that something you would prefer?
A) yes, it's a Macbook with a 4k display connected, so, different sizes, probably a fairly typical config B) yes, I'd definitely prefer that the size doesn't change unless I say so :)
and one more (I can open this as a new report if preferred): C) right now, if I use a keyboard binding to get a window to a certain size and position, dragging it restores the state before this size and position (=dragging undoes it) - this should definitely only happen when user uses the mouse and dragging in the first place, NOT keyboard binding or selecting from the loop menubar menu. It's weird and confusing right now, you don't expect the window to change size and proportions when you drag it.
In other words, if I use mouse to drag a window onto a screen side (aka Windows snap), undoing by dragging away is fine and expected, but undoing by dragging when the snapped windows are created by a keyboard shortcut or menu item is not fine nor expected IMHO.
BTW stellar job otherwise, I love that I can even specify a custom window size (I like smaller windows in the center).
Sorry for the late answer, but I am planning to implement this next!
Anyways, about C), I totally agree! But since that doesn't seem to be too related to multi-monitor setups, I would prefer that you open a new issue for it!