-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[MEGATHREAD] Quake Mode & Global Summon #8888
Comments
## Summary of the Pull Request Does what it says on the can. People can now use `win` in a keybinding to indicate that the chord needs <kbd>win</kbd>. ## References * Done for #653 * See also #8888 ## PR Checklist * [x] Closes #3184 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments For the record, I hate this. But it's great for quake mode, so _meh_. There's shockingly more win keys claimed then you think - many more than the shortcut guide even shows. * `win+b`: Focus the tray? * `win+t`: Focus the taskbar * `win+p`: Project... * `win+c`: The powertoys color picker * `win+v`: cloud clipboard So the list of valid combos is vanishingly small. It's all about that <kbd>win+~</kbd> ## Validation Steps Performed Bound ```json { "keys": [ "win+`" ], "command": "commandPalette" }, ``` and yea, it works as expected
## Summary of the Pull Request Does what it says on the can. People can now use `win` in a keybinding to indicate that the chord needs <kbd>win</kbd>. ## References * Done for microsoft#653 * See also microsoft#8888 ## PR Checklist * [x] Closes microsoft#3184 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments For the record, I hate this. But it's great for quake mode, so _meh_. There's shockingly more win keys claimed then you think - many more than the shortcut guide even shows. * `win+b`: Focus the tray? * `win+t`: Focus the taskbar * `win+p`: Project... * `win+c`: The powertoys color picker * `win+v`: cloud clipboard So the list of valid combos is vanishingly small. It's all about that <kbd>win+~</kbd> ## Validation Steps Performed Bound ```json { "keys": [ "win+`" ], "command": "commandPalette" }, ``` and yea, it works as expected
## Summary of the Pull Request This PR adds some special behavior to the window named "\_quake". * When creating the quake window, it ignores "initialRows" and "initialCols" and opens on the top half of the monitor. - It uses `initialPosition` to determine which monitor this is * It cannot be moved * It can only be vertically resized on the bottom border. * It's always in focus mode. - We should probably have an issue tracking "Allow showing tabs in focus mode"? Maybe? - This one element is maybe the one I'm least attached to When renaming a window to "\_quake", it adopts all those behaviors as well. It does not exit focus mode when leaving QM, nor does it resize back. That seemed unnecessary. ## References * As spec'ed in #9274 * See also #8888 ## PR Checklist * [x] In the pursuit of #653 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated, but I'm not gonna do any of that till quake mode is totally done. ## Detailed Description of the Pull Request / Additional comments Note that this doesn't do things like: * dropdown * global hotkey summon * summon to the current monitor * summon to the current desktop I'm doing #653 _very_ piecemeal, to try and make the PRs less egregious. ## Validation Steps Performed * validated that center on launch still works * validated that QM works on different monitors based on `initialPosition` * validated entering/exiting QM behaves as expected ## TODO! * [ ] When snapping the quake window between desktops with <kbd>win+shift+arrow</kbd>, the window doesn't horizontally re-size to the new monitor dimensions. It should.
## Summary of the Pull Request We don't want it acting as the "most recent window" for windowing behavior. The most recent window should always be some other window. This is being made as an atomic commit because we're probably 50% sure on this one. Maybe people do want new tabs to open up in the quake window! If they're running from the commandline, that's easy. If they're running from the shell context menu, that's **H**ard / impossible currently. $20 someone asks for that if we ship this. That of course might just fall into "explorer context menu settings" though. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Checks a box in #8888 * [x] closes https://github.com/microsoft/terminal/projects/5#card-59030791 * [x] I work here * [x] Tests added * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I mean, this one's super straightforward, not sure what else there is to add. ## Validation Steps Performed Played with this, it works exactly as you'd think.
Adds support for two new actions: * `globalSummon`, which can be used to activate a window using a _global_ (READ: OS-level) hotkey. - accepts an optional `name` argument. When provided, this will attempt to summon with the given name. When omitted, we'll try to summon the most recent window. * `quakeMode` which is `globalSummon` for the `_quake` window. These actions are stored in the actions array, but are read by the `WindowsTerminal` level and bound to the OS in `IslandWindow`. The monarch registers for these keybindings with the OS. When one is pressed, the monarch will recieve a `WM_HOTKEY` message. It'll use that to look up the corresponding action args. It'll use those to try and summon the right window. ## References * #8888: Quake mode megathread * #9274: Spec (**guys seriously i just need one more ✔️**) * #9785: The start of granting "\_quake" super powers ## PR Checklist * [x] Closes #653 - I'm gonna say this closes it for now, though we have _many_ follow-ups in #8888 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Validated that it works with `win` keys * Validated that it works without `win` keys * Validated that it hot-reloads * Validated that it moves to the new monarch * Validated that you can bind both `globalSummon` and `quakeMode` at the same time and do different things * Validated that you can bind `globalSummon` with a name and it creates that name if it doesn't already exist
This adds support for the `desktop` param to the `globalSummon` action. It accepts 3 values: * `toCurrent` (default): The window moves to the current desktop when it's summoned * `any`: We don't care what desktop the window is on. We'll go to the desktop the window is on when we summon it. * `onCurrent`: We'll only try to summon the MRU window on this desktop when summoning a window. * When combined with `name`, if there's a window matching `name`, we'll move it to this desktop. * If there's not a window on this desktop, and `name` is omitted, then we'll make a new window. `quakeMode` was also updated to use `toCurrent` behavior by default. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Checks some boxes in #8888 * [x] closes https://github.com/microsoft/terminal/projects/5#card-59030845 * [x] I work here * [x] Tests added * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments S/O to https://github.com/microsoft/PowerToys, who graciously let us use `VirtualDesktopUtils` for figuring out what desktop is the current desktop. Yea, that's all we needed that entire file for. No, there isn't an API for this (_surprised-pikachu.png_) ## Validation Steps Performed Played with this for a while, and it's amazing.
This adds a `toggleVisibility` parameter to `globalSummon`. * When `true` (default): when you press the global summon keybinding, and the window is currently the foreground window, we'll minimize the window. * When `false`, we'll just do nothing. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Checks a box in #8888 * [x] closes https://github.com/microsoft/terminal/projects/5#card-59030814 * [x] I work here * [ ] No tests for this one. * [ ] yes yes eventually I'll come back on the docs ## Detailed Description of the Pull Request / Additional comments I've got nothing extra to add here. This one's pretty simple. I'm only targeting #9954 since that one laid so much foundation to build on, with the `SummonBehavior` ## Validation Steps Performed Played with this for a while, and it's amazing.
## Summary of the Pull Request <kbd>win+shift+arrows</kbd> can be used to move windows to adjacent monitors. When that happens, we'll new re-calculate the size of the window for the new monitor. ## References * megathread: #8888 ## PR Checklist * [x] Closes #10274 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments In `WM_WINDOWPOSCHANGING`, the OS says "hey, I'm about to do {something} to your window. You cool with that?". We handle that message by: 1. checking if the window was _moved_ as a part of this message 2. getting the monitor that the window will be moved onto 3. If that monitor is different than the monitor the window is currently on, then * calculate how big the quake window should be on that monitor * tell the OS that's where we'd like to be. ## Validation Steps Performed * <kbd>win+shift+arrows</kbd> works right now * normal quake summoning still works right
## Summary of the Pull Request This isn't a fix for #10875, but it is logging that help identify the root cause here. The logging may additionally be helpful for some of the other issues we're seeing elsewhere in the repo, namely #10340. @lhecker is actually working on the fix for #10875, so hopefully this test will help validate. ## References * Regressed in #10666. * logging for #8888 ## PR Checklist * [x] Closes nothing * [x] I work here * [x] Tests added, and they absolutely fail, but they're localtests, so ¯\\\_(ツ)_/¯ * [n/a] Requires documentation to be updated ## details While I was here, I noticed that `KeyBindingsTests::KeyChords` has been broken for some time now. So I fixed that too.
Couldn't find the issue about task manager focus, so posting it here. It also happens with IntelliJ IDEs. |
…tor (#10674) ## Summary of the Pull Request When the quake window is moved to another monitor, re-evaluate it's size for that monitor. ## References * megathread: #8888 * Similar, but not the same: #10274 ## PR Checklist * [x] Closes #10182 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments We'll probably need to do this in a few more places, but I'm breaking PRs into small chunks for easier reviews. ## Validation Steps Performed Summoned the window to a bunch of different resolutions. Where it would use the wrong size before, it no longer does.
#10676) ## Summary of the Pull Request We were making the quake window exactly the width of the monitor it was on, but that didn't account for the 1px of border on either side. ## References * megathread: #8888 ## PR Checklist * [x] Closes #10201 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed It happened before, it doesn't anymore.
## Summary of the Pull Request <kbd>win+shift+arrows</kbd> can be used to move windows to adjacent monitors. When that happens, we'll new re-calculate the size of the window for the new monitor. ## References * megathread: #8888 ## PR Checklist * [x] Closes #10274 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments In `WM_WINDOWPOSCHANGING`, the OS says "hey, I'm about to do {something} to your window. You cool with that?". We handle that message by: 1. checking if the window was _moved_ as a part of this message 2. getting the monitor that the window will be moved onto 3. If that monitor is different than the monitor the window is currently on, then * calculate how big the quake window should be on that monitor * tell the OS that's where we'd like to be. ## Validation Steps Performed * <kbd>win+shift+arrows</kbd> works right now * normal quake summoning still works right
Apologies if this has been discussed elsewhere (I did do a quick search), but I imagine this is UIPI related? If so, my understanding is that you would normally solve that by requesting Curiously enough, when I have Task Manager (or any other high integrity/UWP app) in focus, I can summon the quake window if it is not currently shown, but once it is visible on the desktop I cannot dismiss/focus the quake window using the hotkey (if taskmgr/whatever is in focus). I'm not entirely sure why that is, but (assuming my experience isn't unique) I suspect what's actually happening when a user says they can't summon the window is that is was already present on the desktop, but perhaps out of focus and hidden by other windows (like a maximized browser or something) and it's not capturing the hotkey so it doesn't take focus again. If so that raises a couple of questions in my mind:
The problem also appears to go away for programs like Task Manager if you run the terminal as admin, though that doesn't seem like much of a solution. This doesn't appear to work for UWP apps, though, presumably because of AppContainers and various other things that they do which might as well be magic as far as I know. |
I honestly don't know. The way we make this work is admittedly pretty hacky: terminal/src/cascadia/WindowsTerminal/IslandWindow.cpp Lines 1511 to 1527 in e2b2d9b
I never dug to far into it, but I just assumed that Task Manager was protected s.t. I couldn't Whatever the solution to this is, utimately, it should work for non-quake windows as well. Quake mode is the most visible implementation here, but whatever we come up with should work for any old window. |
Yeah, I am fairly confident UIPI is the mechanism at play there. My understanding is that you're not allowed to Anyway, requesting
Yep, that seems reasonable. Though it may not be the best solution for the problem at hand, I'd still propose always-on-top/auto-dismiss behaviours for quake mode have merit regardless, but that is a separate discussion I guess. |
[Original thread: #653] [Spec: #9274, doc] [Project]
See also Quake Mode FAQ
1.9 tasks
win
key in keybindings #9783)dev/migrie/f/win-in-keybindings
_quake
special #9785)dev/migrie/f/653-special-_quake-window
quakeMode
action activates the_quake
window (or creates one) (PR: AddglobalSummon
action #9854)dev/migrie/f/653-QUAKE-MODE
quakeMode
summons the window to the current desktop (PR: Adddesktop
param toglobalSummon
; set _quake = toCurrent #9954)dev/migrie/f/quake-toCurrent-desktop
quakeMode
/globalSummon
hides the window if it's currently active (PR: When the window is summoned and is already active, minimize it. #9963)quakeMode
does the dropdown dance on entrance (PR: Add property to control dropdown speed of global summon #9977)dev/migrie/f/quake-dropdown
for more progressdev/migrie/f/quake-dropdown-2
has the most research notes in it, for future readers._quake
window from window glomming (PR: Exempt the_quake
window from glomming #9956)quakeMode
summons the window to the current monitor2.0 tasks
globalSummon
to summon a window by name (PR: AddglobalSummon
action #9854)dev/migrie/f/653-QUAKE-MODE
globalSummon
action (PR: AddglobalSummon
action #9854)toggleVisibility
property (PR: When the window is summoned and is already active, minimize it. #9963)desktop
property to control how window summoning interacts with virtual desktopsdev/migrie/f/quake-toCurrent-desktop
monitor
which monitor the window appears on."monitor": "toCurrent"|"any"
for on the current vs where it is (PR Add"monitor": "any"|"toCurrent"|"toMouse"
setting to globalSummon #10092)"monitor": "toMouse"
for to where the mouse pointer is (PR Add"monitor": "any"|"toCurrent"|"toMouse"
setting to globalSummon #10092)"monitor": "onCurrent"
dropdownDuration
property (PR: Add property to control dropdown speed of global summon #9977)initialPosition
and use the current monitor instead.minimizeToTray
setting, and implement it without any sort of flyout_quake
window is hidden when minimized (PR: Hide_quake
window on minimize ALWAYS #10113)alwaysShowTrayIcon
setting_quake
mode should restore the focus mode state, window position that the window had before.Backlog
_quake
window to have some different set of settings - size, profile, etc."_quake
into focus mode. This might be best served by Add per-window-name global settings #9992_quake
windows to be locked to the top half of the display. Probably should be a global setting. Consider Add per-window-name global settings #9992 when authoring this.globalSummon
/quakeMode
to work even when there isn't a running Terminal EnableglobalSummon
/quakeMode
to work even when there isn't a running Terminal #9996globalSummon
a new tab in explorer CWDglobalSummon
a new tab in explorer CWD #10202wt summon
wt summon --profile
The text was updated successfully, but these errors were encountered: