Feature request: hot key drop down ala quake/guake/tilda #924

@oising commented on GitHub (May 10, 2019):

So you mean if you have three monitors (for example), you could hit a different hotkey to cause the terminal to slide down quake console style from whichever monitor you choose?

@oising commented on GitHub (May 10, 2019): So you mean if you have three monitors (for example), you could hit a different hotkey to cause the terminal to slide down quake console style from whichever monitor you choose?

claunia commented

@NOFUNEVER commented on GitHub (May 10, 2019):

So you mean if you have three monitors (for example), you could hit a different hotkey to cause the terminal to slide down quake console style from whichever monitor you choose?

Exactly, exactly. I know it seems a bit outlandish/unnecessary/gimmicky for what's meant to be a heavily used mainstream terminal but I promise you the productivity is what really makes hot key drop downs shine.

Ideally each monitor is has it's own terminal that can be kept open simultaneously with the others.
In nix using 3 instances of Tilda I have it set up so that f1 drops,closes,or select if open but not active the left monitor. F2 does my center screen and f3 does my right. I can use these hot key's to jump between these three terminals if they are open already as well. The end result makes moving between terminals and other background applications a workflow dream. It's also looks pretty dang cool if I do say so myself.

Guake another alternative I like is limited to only one window/instance at a time and it simply drops down on whatever monitor the mouse currently resides in at the time the hot key is pressed. This is also a very neat feature however not what I'm looking for. I wouldn't object to a choice in behavior but lines of code dont grow on trees so made to choose i'd prefer the tilda design.

We really are spoiled terminal wise on the nix side of things and that's what makes Microsoft endeavor to build a new more advanced feature rich terminal so exciting. It really feels like Microsoft is fighting for the time devs and future devs(student here) spend in their operating system and if you pair'd WSL2 with a drop down terminal I know for a fact i'd spend a lot less time booting back and forth between Mint and 10.

@NOFUNEVER commented on GitHub (May 10, 2019): > So you mean if you have three monitors (for example), you could hit a different hotkey to cause the terminal to slide down quake console style from whichever monitor you choose? Exactly, exactly. I know it seems a bit outlandish/unnecessary/gimmicky for what's meant to be a heavily used mainstream terminal but I promise you the productivity is what really makes hot key drop downs shine. Ideally each monitor is has it's own terminal that can be kept open simultaneously with the others. In nix using 3 instances of Tilda I have it set up so that f1 drops,closes,or select if open but not active the left monitor. F2 does my center screen and f3 does my right. I can use these hot key's to jump between these three terminals if they are open already as well. The end result makes moving between terminals and other background applications a workflow dream. It's also looks pretty dang cool if I do say so myself. Guake another alternative I like is limited to only one window/instance at a time and it simply drops down on whatever monitor the mouse currently resides in at the time the hot key is pressed. This is also a very neat feature however not what I'm looking for. I wouldn't object to a choice in behavior but lines of code dont grow on trees so made to choose i'd prefer the tilda design. We really are spoiled terminal wise on the nix side of things and that's what makes Microsoft endeavor to build a new more advanced feature rich terminal so exciting. It really feels like Microsoft is fighting for the time devs and future devs(student here) spend in their operating system and if you pair'd WSL2 with a drop down terminal I know for a fact i'd spend a lot less time booting back and forth between Mint and 10.

claunia commented

@kimbirkelund commented on GitHub (May 10, 2019):

Quake mode would be a requirement for me to switch from ConEmu. However I'd much prefer for it to always open the same instance regardless of which monitor/virtual desktop is currently in focus.

Personally I use win+tilde to open ConEmu, but obviously the shortcut should be configurable.

@kimbirkelund commented on GitHub (May 10, 2019): Quake mode would be a requirement for me to switch from ConEmu. However I'd much prefer for it to always open the same instance regardless of which monitor/virtual desktop is currently in focus. Personally I use win+tilde to open ConEmu, but obviously the shortcut should be configurable.

claunia commented

@cyberhck commented on GitHub (May 16, 2019):

Yes, one instance dropping down, it should drop down on the monitor where our mouse cursor is, and should focus, but it shouldn't show up when you're doing Alt + Tab, so it's feels like it's kinda baked into OS. Like guake.

@cyberhck commented on GitHub (May 16, 2019): Yes, one instance dropping down, it should drop down on the monitor where our mouse cursor is, and should focus, but it shouldn't show up when you're doing Alt + Tab, so it's feels like it's kinda baked into OS. Like guake.

claunia commented

@Jaykul commented on GitHub (May 20, 2019):

@cyberhck are you sure it should be where the mouse is, and not where the currently focused window is?

@Jaykul commented on GitHub (May 20, 2019): @cyberhck are you sure it should be where the mouse is, and not where the currently focused window is?

claunia commented

@NOFUNEVER commented on GitHub (May 20, 2019):

@Jaykul
Guake's default behavior is such that the hot key activates the terminal in what ever monitor the mouse currently resides as Cyberhck described. It also has the option to assign it a specific monitor if so desired. It's limited only in that only one instance can run at at time, something windows Terminal has no issue with. If Windows Terminal could be set up the way guake is with the choice between static or follow behavior all it would need is independent settings per instance to match the functionality of both guake(follow or static) and tilda(multiple instances).

@NOFUNEVER commented on GitHub (May 20, 2019): @Jaykul Guake's default behavior is such that the hot key activates the terminal in what ever monitor the mouse currently resides as Cyberhck described. It also has the option to assign it a specific monitor if so desired. It's limited only in that only one instance can run at at time, something windows Terminal has no issue with. If Windows Terminal could be set up the way guake is with the choice between static or follow behavior all it would need is independent settings per instance to match the functionality of both guake(follow or static) and tilda(multiple instances).

claunia commented

@cyberhck commented on GitHub (May 21, 2019):

Yes, we could have 3 way configuration, one on one specific monitor, one on whatever window is focused, and one where mouse is present, (also it's quite important to have an option to hide from list of application (alt + tab) if this mode is enabled, because I'd imagine users won't want to see that while switching between IDE and browser)

:)

@Jakul, the reason I say where the mouse is present is because when you are browsing through something, mouse is always likely to be in front of your eyes, and if you're using short keys, it's really easy to switch your eyes rather than having to move your mouse all the way.

@cyberhck commented on GitHub (May 21, 2019): Yes, we could have 3 way configuration, one on one specific monitor, one on whatever window is focused, and one where mouse is present, (also it's quite important to have an option to hide from list of application (alt + tab) if this mode is enabled, because I'd imagine users won't want to see that while switching between IDE and browser) :) @Jakul, the reason I say where the mouse is present is because when you are browsing through something, mouse is always likely to be in front of your eyes, and if you're using short keys, it's really easy to switch your eyes rather than having to move your mouse all the way.

claunia commented

@sdistefano commented on GitHub (May 22, 2019):

+1

@sdistefano commented on GitHub (May 22, 2019): +1

claunia commented

@zadjii-msft commented on GitHub (May 22, 2019):

Please don't reply to threads with a "+1" without providing useful additional feedback. Github has a perfectly good +1 that doesn't ping everyone on the thread's inbox right here:

@zadjii-msft commented on GitHub (May 22, 2019): Please don't reply to threads with a "+1" without providing useful additional feedback. Github has a perfectly good +1 that doesn't ping everyone on the thread's inbox right here: ![image](https://user-images.githubusercontent.com/18356694/58183551-2711b300-7c75-11e9-9740-792578a5b121.png)

claunia commented

@nofunatall commented on GitHub (May 29, 2019):

So you mean if you have three monitors (for example), you could hit a different hotkey to cause the terminal to slide down quake console style from whichever monitor you choose?

The default behaviour on multi monitor for Guake is wherever the mouse is is where the terminal drops down.

You can however set it to drop down to whatever monitor you want via the settings if you don't want this behaviour.

@nofunatall commented on GitHub (May 29, 2019): > So you mean if you have three monitors (for example), you could hit a different hotkey to cause the terminal to slide down quake console style from whichever monitor you choose? The default behaviour on multi monitor for Guake is wherever the mouse is is where the terminal drops down. You can however set it to drop down to whatever monitor you want via the settings if you don't want this behaviour.

claunia commented

@zakius commented on GitHub (Jun 24, 2019):

Things I need with this are ability to disable animation and hiding the window completely (from taskbar, alt+tab, win+tab etc.)

Additional option to never show taskbar button would be desired by me too but might be out of scope for this issue

@zakius commented on GitHub (Jun 24, 2019): Things I need with this are ability to disable animation and hiding the window completely (from taskbar, alt+tab, win+tab etc.) Additional option to never show taskbar button would be desired by me too but might be out of scope for this issue

claunia commented

@zikhan commented on GitHub (Jul 16, 2019):

I love the proposal, and it is the only thing that would keep from using it daily (once released). I love using the ctrl+` in ConEmu and don't even use VSCode integrated terminal because of it. However, I'm not sure if I care much about the key binding per monitor idea though.

Also, Would this proposal include starting an instance of the terminal if none were running, similar to other linux terms like xfce terminal dropdown with application shortcut? I wouldn't mind if it were Win+` as a system shortcut, similar to Win+<num> for taskbar shortcuts.

@zikhan commented on GitHub (Jul 16, 2019): I love the proposal, and it is the only thing that would keep from using it daily (once released). I love using the ctrl+\` in ConEmu and don't even use VSCode integrated terminal because of it. However, I'm not sure if I care much about the key binding per monitor idea though. Also, Would this proposal include starting an instance of the terminal if none were running, similar to other linux terms like [xfce terminal dropdown with application shortcut](https://docs.xfce.org/apps/terminal/dropdown)? I wouldn't mind if it were Win+\` as a system shortcut, similar to Win+\<num\> for taskbar shortcuts.

claunia commented

@zakius commented on GitHub (Jul 16, 2019):

That would be doable with shortcut existing somewhere with global hotkey bound to it and that shortcut using CLI to call toggle if some instance is already running. Making it systemwide hotkey seems like a bad idea imo

@zakius commented on GitHub (Jul 16, 2019): That would be doable with shortcut existing somewhere with global hotkey bound to it and that shortcut using CLI to call toggle if some instance is already running. Making it systemwide hotkey seems like a bad idea imo

claunia commented

@stanfieldr commented on GitHub (Jul 16, 2019):

I would consider developing on windows more (currently 95% done on Linux) if I had a terminal that could drop down like guake.

@stanfieldr commented on GitHub (Jul 16, 2019): I would consider developing on windows more (currently 95% done on Linux) if I had a terminal that could drop down like guake.

claunia commented

@mournguard commented on GitHub (Jul 26, 2019):

I mainly use cmder/conemu on windows as well and this is also the main reason I'm not switching yet, especially since I'm using two monitors and (usually) 3 desktops, without a global way to just call down the terminal I essentially have 6 places where the actual window could be, sounds silly, but it's annoying.

Also, many of you mention using a keyboard shortcut for this but you all should consider mapping it on a dedicated mouse button as well, and if possible, gesture. Thank me later.

@mournguard commented on GitHub (Jul 26, 2019): I mainly use cmder/conemu on windows as well and this is also the main reason I'm not switching yet, especially since I'm using two monitors and (usually) 3 desktops, without a global way to just call down the terminal I essentially have 6 places where the actual window could be, sounds silly, but it's annoying. Also, many of you mention using a keyboard shortcut for this but you all should consider mapping it on a dedicated mouse button as well, and if possible, gesture. Thank me later.

claunia commented

@NOFUNEVER commented on GitHub (Jul 30, 2019):

Glad to see other people are excited by the idea of a configurable drop down terminal. It's clear people have very distinct preferences on how these drop downs behave by default but believe most everyone's preference becomes possible so long as

Each instance can be configured for either mouse follow or binding to one monitor.
Each instance can have its own hot key.

Then it doesn't matter what you like its within the realm of configurable possibilities.

I personally use a combo of quake and tilda so that I have one terminal bound to each screen and one that follows the mouse.

@NOFUNEVER commented on GitHub (Jul 30, 2019): Glad to see other people are excited by the idea of a configurable drop down terminal. It's clear people have very distinct preferences on how these drop downs behave by default but believe most everyone's preference becomes possible so long as 1. Each instance can be configured for either mouse follow or binding to one monitor. 2. Each instance can have its own hot key. Then it doesn't matter what you like its within the realm of configurable possibilities. I personally use a combo of quake and tilda so that I have one terminal bound to each screen and one that follows the mouse.

claunia commented

@dluxcru commented on GitHub (Jul 31, 2019):

@NOFUNEVER you have most of what people are asking for right, but @cyberhck and @zakius identified a couple other features that might be important:

Add window focus to list of config options, in addition to monitor binding/mouse follow.
Should have configurable option to not show on alt-tab/taskbar?

It sounds like there is still discussion if this should have multiple instances, like tilda (which I've never used and can't comment on), or single instance, like Guake. Am I missing anything else? If not, we should resolve that question and move towards writing a spec.

(@zakius , you also mentioned a desire to disable dropdown animation. Reason? I don't see anything wrong with that, but a justification would help.)

@dluxcru commented on GitHub (Jul 31, 2019): @NOFUNEVER you have most of what people are asking for right, but @cyberhck and @zakius identified a couple other features that might be important: - Add window focus to list of config options, in addition to monitor binding/mouse follow. - Should have configurable option to not show on alt-tab/taskbar? It sounds like there is still discussion if this should have multiple instances, like tilda (which I've never used and can't comment on), or single instance, like Guake. Am I missing anything else? If not, we should resolve that question and move towards writing a spec. (@zakius , you also mentioned a desire to disable dropdown animation. Reason? I don't see anything wrong with that, but a justification would help.)

claunia commented

@zakius commented on GitHub (Jul 31, 2019):

I dislike animations overall as they steal my focus (if something moves you instinctively look at it, back in the days it could save your life). But there are also what I call blocking animations, ones that you have to wait through before you can take action, preventing you from reading the text or issuing input commands. These are even more disturbing to workflow as you have no other choice than wait, some of them were designed to mark slow execution, but on fast machines they slow you down.

The best approach would be being able to choose animation time with 0 disabling it completely

@zakius commented on GitHub (Jul 31, 2019): I dislike animations overall as they steal my focus (if something moves you instinctively look at it, back in the days it could save your life). But there are also what I call `blocking animations`, ones that you have to wait through before you can take action, preventing you from reading the text or issuing input commands. These are even more disturbing to workflow as you have no other choice than wait, some of them were designed to mark slow execution, but on fast machines they slow you down. The best approach would be being able to choose animation time with 0 disabling it completely

claunia commented

@cyberhck commented on GitHub (Aug 1, 2019):

we don't want animation like mac which is too slow, but guake finishes it's animation in less than a 100ms, I think, so it's snappy, maybe the delay can be a configuration as well, 0 for no animation. Guake animation seems "just right", it's very fast, yet you can see where it's coming from or where it's going.

Adding configuration would be awesome, as someone who doesn't like animation can disable it, or turn it into a slow animation like mac, I'd just do a 80ms or 120ms.

@cyberhck commented on GitHub (Aug 1, 2019): we don't want animation like mac which is too slow, but guake finishes it's animation in less than a 100ms, I think, so it's snappy, maybe the delay can be a configuration as well, 0 for no animation. Guake animation seems "just right", it's very fast, yet you can see where it's coming from or where it's going. Adding configuration would be awesome, as someone who doesn't like animation can disable it, or turn it into a slow animation like mac, I'd just do a 80ms or 120ms.

claunia commented

ConEmu still being a great example here.

@mournguard commented on GitHub (Aug 1, 2019):

@mournguard commented on GitHub (Aug 1, 2019): [ConEmu still being a great example here.](https://conemu.github.io/en/SettingsQuake.html)

claunia commented

@cyberhck commented on GitHub (Aug 2, 2019):

Ahh how I wish ConEmu was a solution for me, it doesn't work for everyone, it's built on top of Hotkey, and anything on top of hot key is detected as trojan (false alarm).

A lot of people are using terminal for work, and their work don't allow them to install something which is detected as a trojan. (same as Qonsole) https://github.com/joedf/Qonsole/issues/9

@cyberhck commented on GitHub (Aug 2, 2019): Ahh how I wish ConEmu was a solution for me, it doesn't work for everyone, it's built on top of Hotkey, and anything on top of hot key is detected as trojan (false alarm). A lot of people are using terminal for work, and their work don't allow them to install something which is detected as a trojan. (same as Qonsole) https://github.com/joedf/Qonsole/issues/9

claunia commented

@jdgregson commented on GitHub (Aug 7, 2019):

Another important thing to consider when implementing this is that the drop-down should appear on the currently active virtual desktop. I use virtual desktops heavily. When I first started using ConEmu, I found that the drop-down terminal would always move me back to desktop 1 and then show the drop-down. I eventually found the settings to get it working as expected in ConEmu, and it is critical that Windows Terminal behave the same way.

@jdgregson commented on GitHub (Aug 7, 2019): Another important thing to consider when implementing this is that the drop-down should appear on the currently active virtual desktop. I use virtual desktops heavily. When I first started using ConEmu, I found that the drop-down terminal would always move me back to desktop 1 and then show the drop-down. I eventually found the settings to get it working as expected in ConEmu, and it is critical that Windows Terminal behave the same way.

claunia commented

@cyberhck commented on GitHub (Aug 8, 2019):

Yeah, that should have been obvious actually :D imagine pressing hot key and terminal appearing on the first one when you're on other workspace.

@cyberhck commented on GitHub (Aug 8, 2019): Yeah, that should have been obvious actually :D imagine pressing hot key and terminal appearing on the first one when you're on other workspace.

claunia commented

@flyingpie commented on GitHub (Aug 8, 2019):

So until our overlords add this to the terminal, I've concocted a simple piece of C# that fixes this for me in the mean time: https://github.com/flyingpie/windows-terminal-quake.

It does Quake-style drop down using CTRL+~ and CTRL+Q, which is totally changeable of course. Currently does fullscreen drop and comes down on the screen + workspace where the mouse is.

Should anyone be drawn, I'm open to suggestions and/or PRs.

@flyingpie commented on GitHub (Aug 8, 2019): So until our overlords add this to the terminal, I've concocted a simple piece of C# that fixes this for me in the mean time: https://github.com/flyingpie/windows-terminal-quake. It does Quake-style drop down using CTRL+~ and CTRL+Q, which is totally changeable of course. Currently does fullscreen drop and comes down on the screen + workspace where the mouse is. Should anyone be drawn, I'm open to suggestions and/or PRs.

claunia commented

@zadjii-msft commented on GitHub (Aug 8, 2019):

@flyingpie That's a pretty neat piece of code you've got there. Looks like most of it would work in c++ as well, so that's good to know.

I just want to re-iterate that while no one on the team is going to have the cycles to do this for 1.0, we'd pretty happily review a contribution from the community. Ideally someone in the community would be able to compile the suggestions and comments from this thread into the Spec Template and submit a PR for that spec. Once that spec is approved, we'd happily review a PR with the code change needed. Looks to me like @flyingpie has really got 90% of the basics down, it'd mostly be polishing the edge cases.

@zadjii-msft commented on GitHub (Aug 8, 2019): @flyingpie That's a pretty neat piece of code you've got there. Looks like most of it would work in c++ as well, so that's good to know. I just want to re-iterate that while no one on the team is going to have the cycles to do this for 1.0, we'd pretty happily review a contribution from the community. Ideally someone in the community would be able to compile the suggestions and comments from this thread into the [Spec Template](https://github.com/microsoft/terminal/blob/master/doc/specs/spec-template.md) and submit a PR for that spec. Once that spec is approved, we'd happily review a PR with the code change needed. Looks to me like @flyingpie has really got 90% of the basics down, it'd mostly be polishing the edge cases.

claunia commented

@rlabrecque commented on GitHub (Aug 10, 2019):

I have a similar usecase. I don't use Quake style, but I do really like the always open terminal.

My ConEmu setup does the following that wt.exe seems to lack so far (in rough order of importance):

My ConEmu literally does not quit except at shutdown or when explicitly asked. If I close the last tab, it's still open just with no tabs.
It launches to the same location every time. (0,0) on my second monitor.
I have a global hotkey to toggle focus of it (ctrl+`).
It does not show up on the task bar. It has a tray icon.
You can only start one instance of it.
It automatically launches upon windows login. (important for the following)
It is the default terminal, automatically consuming other terminals (I.E. If I 'Run' wt.exe, then run cmd.exe, I would expect that wt.exe would just open a new tab with the new cmd.exe tab)***

All of those are roughly blockers for me switching to wt.exe from ConEmu.

Additionally:

Some people would want always on top.
Some people want minimize on focus lost, and those people generally want to disable the minimizing/maximizing animation.
Some want the terminal to jump to their 'active' monitor upon focus.
Some want multiple terminal instances?***

These are all different features which should have their own specs IMO. I'm willing to drive some of this spec process. @zadjii-msft Do you know of any of these bullet points that either have specs already, won't be accomplished for some reason, etc?

*** Tricky?

@rlabrecque commented on GitHub (Aug 10, 2019): I have a similar usecase. I don't use Quake style, but I do really like the always open terminal. My ConEmu setup does the following that wt.exe seems to lack so far (in rough order of importance): 1. My ConEmu literally does not quit except at shutdown or when explicitly asked. If I close the last tab, it's still open just with no tabs. 1. It launches to the same location every time. (0,0) on my second monitor. 1. I have a global hotkey to toggle focus of it (ctrl+`). 1. It does not show up on the task bar. It has a tray icon. 1. You can only start one instance of it. 1. It automatically launches upon windows login. (important for the following) 1. It is the default terminal, automatically consuming other terminals (I.E. If I 'Run' wt.exe, then run cmd.exe, I would expect that wt.exe would just open a new tab with the new cmd.exe tab)*** All of those are roughly blockers for me switching to wt.exe from ConEmu. Additionally: - Some people would want always on top. - Some people want minimize on focus lost, and those people generally want to disable the minimizing/maximizing animation. - Some want the terminal to jump to their 'active' monitor upon focus. - Some want multiple terminal instances?*** These are all different features which should have their own specs IMO. I'm willing to drive some of this spec process. @zadjii-msft Do you know of any of these bullet points that either have specs already, won't be accomplished for some reason, etc? *** Tricky?

claunia commented

@zadjii-msft commented on GitHub (Aug 12, 2019):

So you've listed a number of separate issues, lemme see if I can link them all:

#2080 is the WIP spec for this feature, that's going to turn into a massive spec by the time it's done.
#1043 probably doesn't need a spec TBH, just needs someone to do the work
#653 (this issue)
I frankly haven't heard the request to not have it in the taskbar before. So that definitely doesn't have it's own issue. Having a tray icon seems necessary for not having a taskbar icon, so these could probably be a single spec/task
This falls under Settings documentation (#2080)
Animated backgrounds cause crashes for some people (#2189)
#492 is tracking this, but it's going to require some OS changes likely. This also comes up frequently in #2080.
I could have sworn this had it's own issue, but looks like it doesn't.
Never heard this request before, but sounds neat to me
Seems vaguely similar to this feature TBH. Maybe we should consider both these scenarios in this spec?
Not sure what you mean on this point - do you mean panes, like #1000?

Out of those, #1043, #653, #2189 are all marked "Help-Wanted" 😉

@zadjii-msft commented on GitHub (Aug 12, 2019): So you've listed a number of separate issues, lemme see if I can link them all: 1. #2080 is the WIP spec for this feature, that's going to turn into a massive spec by the time it's done. 2. #1043 probably doesn't need a spec TBH, just needs someone to do the work 3. #653 (this issue) 4. I frankly haven't heard the request to not have it in the taskbar before. So that definitely doesn't have it's own issue. Having a tray icon seems necessary for not having a taskbar icon, so these could probably be a single spec/task 5. This falls under #2080 6. #2189 7. #492 is tracking this, but it's going to require some OS changes likely. This also comes up frequently in #2080. 8. I could have sworn this had it's own issue, but looks like it doesn't. 9. Never heard this request before, but sounds neat to me 10. Seems vaguely similar to this feature TBH. Maybe we should consider both these scenarios in this spec? 11. Not sure what you mean on this point - do you mean panes, like #1000? Out of those, #1043, #653, #2189 are all marked "Help-Wanted" 😉

claunia commented

@zakius commented on GitHub (Aug 12, 2019):

I mentioned 4. before, and to make sure that Terminal doesn't appear on Alt+Tab nor Win+Tab when window is hidden

multiple instances means multiple windows that may but don't have to be spread across multiple screens or virtual desktops I assume, but that would make handling global hotkeys much more complex or even impossible (I think conemu disables multi instance when enabling quake mode)

@zakius commented on GitHub (Aug 12, 2019): I mentioned 4. before, and to make sure that Terminal doesn't appear on Alt+Tab nor Win+Tab when window is hidden multiple instances means multiple windows that may but don't have to be spread across multiple screens or virtual desktops I assume, but that would make handling global hotkeys much more complex or even impossible (I think conemu disables multi instance when enabling quake mode)

claunia commented

@rlabrecque commented on GitHub (Aug 12, 2019):

For 11/"multiple instances means multiple windows", I specifically mean what the OP described here: https://github.com/microsoft/terminal/issues/653#issuecomment-491389892

I don't particularly care about that, but it's a separate related issue. I guess they want multiple global hotkeys to open/activate/focus multiple instances in the same way that I want one hotkey for item # 3 on my list.

@rlabrecque commented on GitHub (Aug 12, 2019): For 11/"multiple instances means multiple windows", I specifically mean what the OP described here: https://github.com/microsoft/terminal/issues/653#issuecomment-491389892 I don't particularly care about that, but it's a separate related issue. I guess they want multiple global hotkeys to open/activate/focus multiple instances in the same way that I want one hotkey for item # 3 on my list.

claunia commented

@nofunatall commented on GitHub (Sep 16, 2019):

@zakius

I mentioned 4. before, and to make sure that Terminal doesn't appear on Alt+Tab nor Win+Tab when window is hidden

multiple instances means multiple windows that may but don't have to be spread across multiple screens or virtual desktops I assume, but that would make handling global hotkeys much more complex or even impossible (I think conemu disables multi instance when enabling quake mode)

Multiple instances disabled is what happens on ConEmu when quake dropdown is used.
It's near impossible to handle that behaviour in a logical manner you must utilize your tabs or use a terminal multiplexer if you want something like multiple instances WITH quake dropdown.

EDIT:
You could possibly work in something where the first terminal window opened is the master and this is the window that is always called down when using the Quake hotkey.

Could be tricky to work that in with tab support - which perhaps is why no other terminal that I know of supports that behaviour. There is also some edge case to consider in that scenario like what happens if you close your main master window and there is a secondary window still open - would the hotkey continue ignoring this secondary terminal window etc.

For ConEmu when Quake is enabled and you try to open ConEmu again (Say from the desktop shortcut) it won't open a new window, instead it will just bring to focus the existing running terminal.

@nofunatall commented on GitHub (Sep 16, 2019): @zakius > > > I mentioned 4. before, and to make sure that Terminal doesn't appear on Alt+Tab nor Win+Tab when window is hidden > > multiple instances means multiple windows that may but don't have to be spread across multiple screens or virtual desktops I assume, but that would make handling global hotkeys much more complex or even impossible (I think conemu disables multi instance when enabling quake mode) Multiple instances disabled is what happens on ConEmu when quake dropdown is used. It's near impossible to handle that behaviour in a logical manner you must utilize your tabs or use a terminal multiplexer if you want something like multiple instances WITH quake dropdown. EDIT: You could possibly work in something where the first terminal window opened is the master and this is the window that is always called down when using the Quake hotkey. Could be tricky to work that in with tab support - which perhaps is why no other terminal that I know of supports that behaviour. There is also some edge case to consider in that scenario like what happens if you close your main master window and there is a secondary window still open - would the hotkey continue ignoring this secondary terminal window etc. For ConEmu when Quake is enabled and you try to open ConEmu again (Say from the desktop shortcut) it won't open a new window, instead it will just bring to focus the existing running terminal.

claunia commented

@zakius commented on GitHub (Sep 16, 2019):

You could possibly work in something where the first terminal window opened is the master and this is the window that is always called down when using the Quake hotkey.

there's also the possibility of allowing to run single instance per physical screen per virtual desktop and this way main hotkey would always bring up the instance on your current active VD and screen, but that's pretty complicated, I think disabling multiple instances is reasonable

@zakius commented on GitHub (Sep 16, 2019): > You could possibly work in something where the first terminal window opened is the master and this is the window that is always called down when using the Quake hotkey. there's also the possibility of allowing to run single instance per physical screen per virtual desktop and this way main hotkey would always bring up the instance on your current active VD and screen, but that's pretty complicated, I think disabling multiple instances is reasonable

claunia commented

@mournguard commented on GitHub (Sep 16, 2019):

I think multiple instances can be ignored if the tabs keep being improved on and the quake-style window can be called from anywhere. At least for now.

@mournguard commented on GitHub (Sep 16, 2019): I think multiple instances can be ignored if the tabs keep being improved on and the quake-style window can be called from anywhere. At least for now.

claunia commented

@nofunatall commented on GitHub (Sep 16, 2019):

there's also the possibility of allowing to run single instance per physical screen per virtual desktop and this way main hotkey would always bring up the instance on your current active VD and screen, but that's pretty complicated, I think disabling multiple instances is reasonable

I wouldn't ignore multiple instances entirely - sometimes it is very handy to have open a terminal on one screen that streams logs or shows system load while working within another terminal on na adjacent screen.

I have previously been using Ubuntu desktop for the last few years (just went back to Windows since WSL v2) and since Guake and the Ubuntu terminal are very similar in terms of responsiveness, UI design / themes etc I often had the default Ubuntu terminal open on my vertical screen watching logs and system load.

That is obviously the easy way around the issue if multiple instances with dropdown is disabled - Use a different terminal.
Problem is most terminals on Windows are complete garbage (Hence this project ofc).

@nofunatall commented on GitHub (Sep 16, 2019): > there's also the possibility of allowing to run single instance per physical screen per virtual desktop and this way main hotkey would always bring up the instance on your current active VD and screen, but that's pretty complicated, I think disabling multiple instances is reasonable I wouldn't ignore multiple instances entirely - sometimes it is very handy to have open a terminal on one screen that streams logs or shows system load while working within another terminal on na adjacent screen. I have previously been using Ubuntu desktop for the last few years (just went back to Windows since WSL v2) and since Guake and the Ubuntu terminal are very similar in terms of responsiveness, UI design / themes etc I often had the default Ubuntu terminal open on my vertical screen watching logs and system load. That is obviously the easy way around the issue if multiple instances with dropdown is disabled - Use a different terminal. Problem is most terminals on Windows are complete garbage (Hence this project ofc).

claunia commented

@NOFUNEVER commented on GitHub (Sep 16, 2019):

the extra instances were with multiple monitors in mind when I suggested
it. One per monitor, each with its own hot key. I use a portrait landscape
portrait set up at home and while running mint have guake running in the
center but it doesn't offer the extra instances tilda has so I use it on
the exterior portrait monitors.

On Mon, Sep 16, 2019 at 2:00 PM nofunatall notifications@github.com wrote:

there's also the possibility of allowing to run single instance per
physical screen per virtual desktop and this way main hotkey would always
bring up the instance on your current active VD and screen, but that's
pretty complicated, I think disabling multiple instances is reasonable

I wouldn't ignore multiple instances entirely - sometimes it is very handy
to have open a terminal on one screen that streams logs or shows system
load while working within another terminal on na adjacent screen.

I have previously been using Ubuntu desktop for the last few years (just
went back to Windows since WSL v2) and since Guake and the Ubuntu terminal
are very similar in terms of responsiveness, UI design / themes etc I often
had the default Ubuntu terminal open on my vertical screen watching logs
and system load.

That is obviously the easy way around the issue if multiple instances with
dropdown is disabled - Use a different terminal.
Problem is most terminals on Windows are complete garbage (Hence this
project ofc).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/terminal/issues/653?email_source=notifications&email_token=ACAH5BIA5ZPETCBZK77LMVLQJ7XYVA5CNFSM4HL735C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD62QC3Q#issuecomment-531956078,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACAH5BM722EZEB5LQBXGW6TQJ7XYVANCNFSM4HL735CQ
.

@NOFUNEVER commented on GitHub (Sep 16, 2019): the extra instances were with multiple monitors in mind when I suggested it. One per monitor, each with its own hot key. I use a portrait landscape portrait set up at home and while running mint have guake running in the center but it doesn't offer the extra instances tilda has so I use it on the exterior portrait monitors. On Mon, Sep 16, 2019 at 2:00 PM nofunatall <notifications@github.com> wrote: > there's also the possibility of allowing to run single instance per > physical screen per virtual desktop and this way main hotkey would always > bring up the instance on your current active VD and screen, but that's > pretty complicated, I think disabling multiple instances is reasonable > > I wouldn't ignore multiple instances entirely - sometimes it is very handy > to have open a terminal on one screen that streams logs or shows system > load while working within another terminal on na adjacent screen. > > I have previously been using Ubuntu desktop for the last few years (just > went back to Windows since WSL v2) and since Guake and the Ubuntu terminal > are very similar in terms of responsiveness, UI design / themes etc I often > had the default Ubuntu terminal open on my vertical screen watching logs > and system load. > > That is obviously the easy way around the issue if multiple instances with > dropdown is disabled - Use a different terminal. > Problem is most terminals on Windows are complete garbage (Hence this > project ofc). > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/microsoft/terminal/issues/653?email_source=notifications&email_token=ACAH5BIA5ZPETCBZK77LMVLQJ7XYVA5CNFSM4HL735C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD62QC3Q#issuecomment-531956078>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ACAH5BM722EZEB5LQBXGW6TQJ7XYVANCNFSM4HL735CQ> > . >

claunia commented

@mlewand commented on GitHub (Sep 17, 2019):

Guys, we clearly have two separate issues here. Could we edit this one to just be about the "Quake style" (global/single terminal) hotkey?

Then a second issue, that would be blocked by this one, to enable assigning a dedicated "Quake style" hotkey to a different displays.

The first one seems to be more popular and desired. I'd love to see the second one too (cool idea @NOFUNEVER never thought of such feature, seems useful), but it would be nice if we could clear up the topic a bit.

@mlewand commented on GitHub (Sep 17, 2019): Guys, we clearly have two separate issues here. Could we edit this one to just be about the "Quake style" (global/single terminal) hotkey? Then a second issue, that would be blocked by this one, to enable assigning a dedicated "Quake style" hotkey to a different displays. The first one seems to be more popular and desired. I'd **love** to see the second one too (cool idea @NOFUNEVER never thought of such feature, seems useful), but it would be nice if we could clear up the topic a bit.

claunia commented

https://github.com/microsoft/terminal/issues/653#issuecomment-520419611

@rlabrecque commented on GitHub (Sep 19, 2019):

The OP's issue is actually more of the second, despite the name of this issue. Regardless, I think having a hotkey open a single terminal is largely blocked by #2080. We can't really have a hotkey open a single terminal until we can enforce a single terminal.

This is the best breakdown I think.

@rlabrecque commented on GitHub (Sep 19, 2019): The OP's issue is actually more of the second, despite the name of this issue. Regardless, I think having a hotkey open a single terminal is largely blocked by #2080. We can't really have a hotkey open a single terminal until we can enforce a single terminal. https://github.com/microsoft/terminal/issues/653#issuecomment-520419611 This is the best breakdown I think.

claunia commented

@mlewand commented on GitHub (Sep 19, 2019):

@rlabrecque Yes, I know that original issue was related to more fancier solution, but looking at the comments most people expressed a desire for "quake"-style only, much less people were interested in custom hotkeys for any display.

That's why I proposed converting this issue into a quake-style related and extract the followup feature request to a separate issue where we'll be able to track it too.

@mlewand commented on GitHub (Sep 19, 2019): @rlabrecque Yes, I know that original issue was related to more fancier solution, but looking at the comments most people expressed a desire for "quake"-style only, much less people were interested in custom hotkeys for any display. That's why I proposed converting this issue into a quake-style related and extract the followup feature request to a separate issue where we'll be able to track it too.

claunia commented

@ThatRendle commented on GitHub (Oct 11, 2019):

It seems to me this needs to be broken down into multiple issues for each of the various features, starting with the fundamental hotkey-to-toggle-visibility feature. That can be done without any of the other features, right?

With multiple issues, it would be much easier to see what the demand was for each particular twist on the recipe and prioritize development. It does seem like the minimum viable feature would scratch a lot of people's itches.

@ThatRendle commented on GitHub (Oct 11, 2019): It seems to me this needs to be broken down into multiple issues for each of the various features, starting with the fundamental hotkey-to-toggle-visibility feature. That can be done without any of the other features, right? With multiple issues, it would be much easier to see what the demand was for each particular twist on the recipe and prioritize development. It does seem like the minimum viable feature would scratch a lot of people's itches.

claunia commented

@rlabrecque commented on GitHub (Oct 11, 2019):

Is that not what comment https://github.com/microsoft/terminal/issues/653#issuecomment-520419611 is describing?

@rlabrecque commented on GitHub (Oct 11, 2019): Is that not what comment https://github.com/microsoft/terminal/issues/653#issuecomment-520419611 is describing?

claunia commented

@alirezajm commented on GitHub (Oct 12, 2019):

For anyone waiting for this to switch from conemu (like myself), etc. You can use autohotkey and a pinned taskbar item as a workaround.

autohotkey script:

^`::Send #5

This will map ctrl+` to winkey+5, change that to your needs.

@alirezajm commented on GitHub (Oct 12, 2019): For anyone waiting for this to switch from conemu (like myself), etc. You can use autohotkey and a pinned taskbar item as a workaround. autohotkey script: ``` ^`::Send #5 ``` This will map ctrl+` to winkey+5, change that to your needs.

claunia commented

@zakius commented on GitHub (Oct 13, 2019):

the tool provided by flyingpie is much better: doesn't require pinning and hides taskbar button completely, tbh I'm using it with other app (since Terminal misses few other things too)

@zakius commented on GitHub (Oct 13, 2019): the tool provided by flyingpie is much better: doesn't require pinning and hides taskbar button completely, tbh I'm using it with other app (since Terminal misses few other things too)

claunia commented

@kimbirkelund commented on GitHub (Oct 13, 2019):

Taking the AutoHotKey solution a bit further:

#SC29::ToggleTerminal()

ShowAndPositionTerminal()
{
    WinShow ahk_class CASCADIA_HOSTING_WINDOW_CLASS
    WinActivate ahk_class CASCADIA_HOSTING_WINDOW_CLASS

    WinMove, ahk_class CASCADIA_HOSTING_WINDOW_CLASS,, -5, -10, A_ScreenWidth + 10, A_ScreenHeight * 0.7,
}

ToggleTerminal()
{
    WinMatcher := "ahk_class CASCADIA_HOSTING_WINDOW_CLASS"

    DetectHiddenWindows, On

    if WinExist(WinMatcher)
    ; Window Exists
    {
        DetectHiddenWindows, Off

        ; Check if its hidden
        if !WinExist(WinMatcher) || !WinActive(WinMatcher)
        {
            ShowAndPositionTerminal()
        }
        else if WinExist(WinMatcher)
        {
            ; Script sees it without detecting hidden windows, so..
            WinHide ahk_class CASCADIA_HOSTING_WINDOW_CLASS
            Send !{Esc}
        }
    }
    else
    {
        Run "c:\Users\kim\AppData\Local\Microsoft\WindowsApps\wt.exe"
        Sleep, 1000
        ShowAndPositionTerminal()
    }
}

This script binds win+½ (on Danish keyboard, the top left button below escape) to a function that brings a running terminal instance into focus, or starts a new instance if non is running, and resizes and positions it "correctly". If terminal is already in focus it hides the window (so it doesn't show up in alt+tab).

@kimbirkelund commented on GitHub (Oct 13, 2019): Taking the AutoHotKey solution a bit further: ``` #SC29::ToggleTerminal() ShowAndPositionTerminal() { WinShow ahk_class CASCADIA_HOSTING_WINDOW_CLASS WinActivate ahk_class CASCADIA_HOSTING_WINDOW_CLASS WinMove, ahk_class CASCADIA_HOSTING_WINDOW_CLASS,, -5, -10, A_ScreenWidth + 10, A_ScreenHeight * 0.7, } ToggleTerminal() { WinMatcher := "ahk_class CASCADIA_HOSTING_WINDOW_CLASS" DetectHiddenWindows, On if WinExist(WinMatcher) ; Window Exists { DetectHiddenWindows, Off ; Check if its hidden if !WinExist(WinMatcher) || !WinActive(WinMatcher) { ShowAndPositionTerminal() } else if WinExist(WinMatcher) { ; Script sees it without detecting hidden windows, so.. WinHide ahk_class CASCADIA_HOSTING_WINDOW_CLASS Send !{Esc} } } else { Run "c:\Users\kim\AppData\Local\Microsoft\WindowsApps\wt.exe" Sleep, 1000 ShowAndPositionTerminal() } } ``` This script binds win+½ (on Danish keyboard, the top left button below escape) to a function that brings a running terminal instance into focus, or starts a new instance if non is running, and resizes and positions it "correctly". If terminal is already in focus it hides the window (so it doesn't show up in alt+tab).

claunia commented

@wizcas commented on GitHub (Oct 19, 2019):

I updated @kimbirkelund solution a bit, so to fix the window size error in case you don't have the taskbar docked at the bottom as same as I do.

You can find the code at my gist here, or copy it directly from below:

; How much height of screen size the terminal window takes.
VRatio := 0.8
; The path to the Windows Terminal exe file.
WtPath = "%LOCALAPPDATA%\Microsoft\WindowsApps\wt.exe"

#SC29::ToggleTerminal()

ShowAndPositionTerminal()
{
    ScreenX := GetScreenLeft()
    ScreenY := GetScreenTop()
    ScreenWidth := GetScreenWidth()
    ScreenHeight := GetScreenHeight()
    global VRatio

    WinShow ahk_class CASCADIA_HOSTING_WINDOW_CLASS
    WinActivate ahk_class CASCADIA_HOSTING_WINDOW_CLASS

    WinMove, ahk_class CASCADIA_HOSTING_WINDOW_CLASS,, ScreenX-5, ScreenY-10, ScreenWidth+10, ScreenHeight * VRatio,
}

ToggleTerminal()
{
    WinMatcher := "ahk_class CASCADIA_HOSTING_WINDOW_CLASS"

    DetectHiddenWindows, On

    if WinExist(WinMatcher)
    ; Window Exists
    {
        DetectHiddenWindows, Off

        ; Check if its hidden
        if !WinExist(WinMatcher) || !WinActive(WinMatcher)
        {
            ShowAndPositionTerminal()
        }
        else if WinExist(WinMatcher)
        {
            ; Script sees it without detecting hidden windows, so..
            WinHide ahk_class CASCADIA_HOSTING_WINDOW_CLASS
            Send !{Esc}
        }
    }
    else
    {
        global WtPath
        Run %WtPath%
        Sleep, 1000
        ShowAndPositionTerminal()
    }
}

; Gets the edge that the taskbar is docked to.  Returns:
;   "top"
;   "right"
;   "bottom"
;   "left"
GetTaskbarEdge() {
  WinGetPos,TX,TY,TW,TH,ahk_class Shell_TrayWnd,,,

  if (TW = A_ScreenWidth) { ; Vertical Taskbar
    if (TY = 0) {
      return "top"
    } else {
      return "bottom"
    }
  } else { ; Horizontal Taskbar
    if (TX = 0) {
      return "left"
    } else {
      return "right"
    }
  }
}

GetScreenTop() {
  WinGetPos,TX,TY,TW,TH,ahk_class Shell_TrayWnd,,,
  TaskbarEdge := GetTaskbarEdge()

  if (TaskbarEdge = "top") {
    return TH
  } else {
    return 0
  }
}

GetScreenLeft() {
  WinGetPos,TX,TY,TW,TH,ahk_class Shell_TrayWnd,,,
  TaskbarEdge := GetTaskbarEdge()

  if (TaskbarEdge = "left") {
    return TW
  } else {
    return 0
  }
}

GetScreenWidth() {
  WinGetPos,TX,TY,TW,TH,ahk_class Shell_TrayWnd,,,
  TaskbarEdge := GetTaskbarEdge()

  if (TaskbarEdge = "top" or TaskbarEdge = "bottom") {
    return A_ScreenWidth
  } else {
    return A_ScreenWidth - TW
  }
}

GetScreenHeight() {
  WinGetPos,TX,TY,TW,TH,ahk_class Shell_TrayWnd,,,
  TaskbarEdge := GetTaskbarEdge()

  if (TaskbarEdge = "top" or TaskbarEdge = "bottom") {
    return A_ScreenHeight - TH
  } else {
    return A_ScreenHeight
  }
}

@wizcas commented on GitHub (Oct 19, 2019): I updated @kimbirkelund solution a bit, so to fix the window size error in case you don't have the taskbar docked at the bottom as same as I do. You can find the code at my gist [here](https://gist.github.com/wizcas/ca8b85281986edace28a87db9c1e7cd5), or copy it directly from below: ``` ahk ; How much height of screen size the terminal window takes. VRatio := 0.8 ; The path to the Windows Terminal exe file. WtPath = "%LOCALAPPDATA%\Microsoft\WindowsApps\wt.exe" #SC29::ToggleTerminal() ShowAndPositionTerminal() { ScreenX := GetScreenLeft() ScreenY := GetScreenTop() ScreenWidth := GetScreenWidth() ScreenHeight := GetScreenHeight() global VRatio WinShow ahk_class CASCADIA_HOSTING_WINDOW_CLASS WinActivate ahk_class CASCADIA_HOSTING_WINDOW_CLASS WinMove, ahk_class CASCADIA_HOSTING_WINDOW_CLASS,, ScreenX-5, ScreenY-10, ScreenWidth+10, ScreenHeight * VRatio, } ToggleTerminal() { WinMatcher := "ahk_class CASCADIA_HOSTING_WINDOW_CLASS" DetectHiddenWindows, On if WinExist(WinMatcher) ; Window Exists { DetectHiddenWindows, Off ; Check if its hidden if !WinExist(WinMatcher) || !WinActive(WinMatcher) { ShowAndPositionTerminal() } else if WinExist(WinMatcher) { ; Script sees it without detecting hidden windows, so.. WinHide ahk_class CASCADIA_HOSTING_WINDOW_CLASS Send !{Esc} } } else { global WtPath Run %WtPath% Sleep, 1000 ShowAndPositionTerminal() } } ; Gets the edge that the taskbar is docked to. Returns: ; "top" ; "right" ; "bottom" ; "left" GetTaskbarEdge() { WinGetPos,TX,TY,TW,TH,ahk_class Shell_TrayWnd,,, if (TW = A_ScreenWidth) { ; Vertical Taskbar if (TY = 0) { return "top" } else { return "bottom" } } else { ; Horizontal Taskbar if (TX = 0) { return "left" } else { return "right" } } } GetScreenTop() { WinGetPos,TX,TY,TW,TH,ahk_class Shell_TrayWnd,,, TaskbarEdge := GetTaskbarEdge() if (TaskbarEdge = "top") { return TH } else { return 0 } } GetScreenLeft() { WinGetPos,TX,TY,TW,TH,ahk_class Shell_TrayWnd,,, TaskbarEdge := GetTaskbarEdge() if (TaskbarEdge = "left") { return TW } else { return 0 } } GetScreenWidth() { WinGetPos,TX,TY,TW,TH,ahk_class Shell_TrayWnd,,, TaskbarEdge := GetTaskbarEdge() if (TaskbarEdge = "top" or TaskbarEdge = "bottom") { return A_ScreenWidth } else { return A_ScreenWidth - TW } } GetScreenHeight() { WinGetPos,TX,TY,TW,TH,ahk_class Shell_TrayWnd,,, TaskbarEdge := GetTaskbarEdge() if (TaskbarEdge = "top" or TaskbarEdge = "bottom") { return A_ScreenHeight - TH } else { return A_ScreenHeight } } ```

claunia commented

@alenbasic commented on GitHub (Oct 22, 2019):

I don't want to continue to take this feature request off track but I wanted to share the changes I made to the work @wizcas and @kimbirkelund have already done. Never really used AHK before so it's rather hackish but in short I added a menu and a settings file so you can change the following:

terminal height
terminal opacity
terminal font type and size
color scheme

All this without recompiling the file or opening up the JSON file and editing it manually. It saves the non profile.json settings (e.g. terminal size) in its own settings.ini file in the same dir. Happy to accept changes to it if anyone wants to contribute. I will also at some point add a theme creator here as it was a bit of a chore converting over a Monokai theme I am currently using (in my gists if anyone wants to suss it out). Here's a small preview of Settings Menu:

EDIT: Updated screenshot

You can get the code here: https://gist.github.com/alenbasic/004c5abeb4cc0e0b31b7681371d48898

@alenbasic commented on GitHub (Oct 22, 2019): I don't want to continue to take this feature request off track but I wanted to share the changes I made to the work @wizcas and @kimbirkelund have already done. Never really used AHK before so it's rather hackish but in short I added a menu and a settings file so you can change the following: * terminal height * terminal opacity * terminal font type and size * color scheme All this without recompiling the file or opening up the JSON file and editing it manually. It saves the non profile.json settings (e.g. terminal size) in its own settings.ini file in the same dir. Happy to accept changes to it if anyone wants to contribute. I will also at some point add a theme creator here as it was a bit of a chore converting over a Monokai theme I am currently using (in my gists if anyone wants to suss it out). Here's a small preview of Settings Menu: ![image](https://user-images.githubusercontent.com/2830042/67631067-84c1bf80-f8e5-11e9-82f1-25ca949bbca6.png) EDIT: Updated screenshot You can get the code here: https://gist.github.com/alenbasic/004c5abeb4cc0e0b31b7681371d48898

claunia commented

@pandasauce commented on GitHub (Nov 11, 2019):

One of the linked duplicate issues mentioned including tmux control mode support, something that is currently only supported by iTerm on Mac OS. It is an incredibly powerful piece of functionality, but to my knowledge, all attempts to implement it in other terminals died a silent death of unmaintained forks. It would be awesome to have it outside of Mac OS.

@pandasauce commented on GitHub (Nov 11, 2019): One of the linked duplicate issues mentioned including tmux control mode support, something that is currently only supported by iTerm on Mac OS. It is an incredibly powerful piece of functionality, but to my knowledge, all attempts to implement it in other terminals died a silent death of unmaintained forks. It would be awesome to have it outside of Mac OS.

claunia commented

@dotjosh commented on GitHub (Nov 11, 2019):

I went ahead and started a project, pretty much because of this feature. https://github.com/dotjosh/WinTermPlus

@dotjosh commented on GitHub (Nov 11, 2019): I went ahead and started a project, pretty much because of this feature. https://github.com/dotjosh/WinTermPlus

claunia commented

@pandasauce commented on GitHub (Nov 14, 2019):

@dotjosh That looks great! Is there any reason why you implemented that as a standalone tool and not a PR? How much effort would it be to merge it?

@pandasauce commented on GitHub (Nov 14, 2019): @dotjosh That looks great! Is there any reason why you implemented that as a standalone tool and not a PR? How much effort would it be to merge it?

claunia commented

@dotjosh commented on GitHub (Nov 14, 2019):

@dotjosh That looks great! Is there any reason why you implemented that as a standalone tool and not a PR? How much effort would it be to merge it?

I'm strong in C#/WPF and I was able to get it done quickly. I'd be willing to help port it if we are happy with the behavior.

@dotjosh commented on GitHub (Nov 14, 2019): > @dotjosh That looks great! Is there any reason why you implemented that as a standalone tool and not a PR? How much effort would it be to merge it? I'm strong in C#/WPF and I was able to get it done quickly. I'd be willing to help port it if we are happy with the behavior.

claunia commented

@zadjii-msft commented on GitHub (Nov 14, 2019):

Honestly I think that looks super cool. I'd definitely be happy to review that PR.

It might be a little tricky to port the taskbar tray bits to the more UWP-like model we have (you'll probably need to muck with the package.appxmanifest), this tutorial looked good though. It would also probably make more sense to put the settings for the size to open the window at within profiles.json, and have the binding defined in there as well (even if it doesn't actually do anything in the TerminalApp, since I presume the binding would need to be registered with the OS itself. I'm sure there's a way to do it in C++, though I don't know what it is 😄

Just quoting something I've said before:

I just want to re-iterate that while no one on the team is going to have the cycles to do this for 1.0, we'd pretty happily review a contribution from the community. Ideally someone in the community would be able to compile the suggestions and comments from this thread into the Spec Template and submit a PR for that spec. Once that spec is approved, we'd happily review a PR with the code change needed. Looks to me like ~~@flyingpie~~ @dotjosh has really got 90% of the basics down, it'd mostly be polishing the edge cases.

Honestly we don't really need everything in the spec template filled out, I'd just really like to make sure that whatever contribution we accept has thought out the edge cases here, and clearly defines the behavior for those cases. Namely:

What happens when the user doesn't yet have a Terminal instance open, and they press the global hotkey?
What happens when the user has multiple Terminal windows open? Which one opens? Does nothing happen in that case?
- With multiple terminal windows open, and one terminal currently focused, does the global hotkey hide the active window, or summon a minimized one?
Can the user choose to have the window appear maximized? Fullscreen?

@zadjii-msft commented on GitHub (Nov 14, 2019): Honestly I think that looks super cool. I'd definitely be happy to review that PR. It might be a little tricky to port the taskbar tray bits to the more UWP-like model we have (you'll probably need to muck with the package.appxmanifest), [this tutorial looked good though](https://stefanwick.com/2017/06/24/uwp-app-with-systray-extension/). It would also probably make more sense to put the settings for the size to open the window at within `profiles.json`, and have the binding defined in there as well (even if it doesn't actually do anything in the TerminalApp, since I presume the binding would need to be registered with the OS itself. I'm sure there's a way to do it in C++, though I don't know what it is 😄 Just quoting something I've said before: > I just want to re-iterate that while no one on the team is going to have the cycles to do this for 1.0, we'd pretty happily review a contribution from the community. Ideally someone in the community would be able to compile the suggestions and comments from this thread into the Spec Template and submit a PR for that spec. Once that spec is approved, we'd happily review a PR with the code change needed. Looks to me like ~~@flyingpie~~ @dotjosh has really got 90% of the basics down, it'd mostly be polishing the edge cases. Honestly we don't really need _everything_ in the spec template filled out, I'd just really like to make sure that whatever contribution we accept has thought out the edge cases here, and clearly defines the behavior for those cases. Namely: * What happens when the user doesn't yet have a Terminal instance open, and they press the global hotkey? * What happens when the user has multiple Terminal windows open? Which one opens? Does _nothing_ happen in that case? - With multiple terminal windows open, and one terminal currently focused, does the global hotkey hide the active window, or summon a minimized one? * Can the user choose to have the window appear maximized? Fullscreen?

claunia commented

@rlabrecque commented on GitHub (Nov 14, 2019):

What happens when the user doesn't yet have a Terminal instance open, and they press the global hotkey?

I think it depends on what Terminal instance is exactly. If Terminal is not running, then nothing should happen. I don't think there should be a service or something hooking that. If there are no shells left in Terminal, it should still be running, waiting for a new shell to open. Quitting Terminal would need to be more explicit.

What happens when the user has multiple Terminal windows open? Which one opens? Does nothing happen in that case?
With multiple terminal windows open, and one terminal currently focused, does the global hotkey hide the active window, or summon a minimized one?

I think the general assumption is this mode would only allow one terminal instance. Launching the executable a second time would merely focus the terminal, possibly launching a new default shell in it? (Much like UWP apps function. Open Settings, then focus something else, then open Settings again, only one instance.)

Can the user choose to have the window appear maximized? Fullscreen?

I don't see why not if both of those are supported currently. 👍 The hotkey would function roughly the same as minimizing/restoring from minimized in both of those cases.

@rlabrecque commented on GitHub (Nov 14, 2019): * What happens when the user doesn't yet have a Terminal instance open, and they press the global hotkey? I think it depends on what Terminal instance is exactly. If Terminal is not running, then nothing should happen. I don't think there should be a service or something hooking that. If there are no shells left in Terminal, it should still be running, waiting for a new shell to open. Quitting Terminal would need to be more explicit. * What happens when the user has multiple Terminal windows open? Which one opens? Does nothing happen in that case? * With multiple terminal windows open, and one terminal currently focused, does the global hotkey hide the active window, or summon a minimized one? I think the general assumption is this mode would only allow one terminal instance. Launching the executable a second time would merely focus the terminal, possibly launching a new default shell in it? (Much like UWP apps function. Open Settings, then focus something else, then open Settings again, only one instance.) * Can the user choose to have the window appear maximized? Fullscreen? I don't see why not if both of those are supported currently. 👍 The hotkey would function roughly the same as minimizing/restoring from minimized in both of those cases.

claunia commented

@pandasauce commented on GitHub (Nov 15, 2019):

May I suggest starting with the user experience of other popular terminals and altering it from there if they are suboptimal?

What happens when the user doesn't yet have a Terminal instance open, and they press the global hotkey?

Nothing, because the terminal is not running. Moreover, the hotkey should be released for other programs to use in this case. This is how ConEmu and Terminator behave.

What happens when the user has multiple Terminal windows open? Which one opens? Does nothing happen in that case?

If single instance setting is active: there can be no multiple windows open.

If single instance setting is not active, Terminator sends the command to all instances and they all toggle states. This might be the simplest solution; it doesn't make much sense to use quake mode with multiple instances and this way terminals won't get permanently stuck in hidden state (terminator hides the window from the taskbar in hidden state).

ConEmu: enabling quake mode enforces single instance mode and grays out the check box. This makes more sense behavior-wise, but introduces more complexity.

I don't think the absence of single instance mode (#2227) should get in the way of implementing this functionality.

With multiple terminal windows open, and one terminal currently focused, does the global hotkey hide the active window, or summon a minimized one?

See above - both. It toggles their states.

Can the user choose to have the window appear maximized? Fullscreen?

In both ConEmu and Terminator this is not relevant to quake mode, the window gets restored into whatever state it was in before being toggled hidden. If it was full screen, it restores to full screen; same for maximized and non-maximized windows.

@pandasauce commented on GitHub (Nov 15, 2019): May I suggest starting with the user experience of other popular terminals and altering it from there if they are suboptimal? * What happens when the user doesn't yet have a Terminal instance open, and they press the global hotkey? Nothing, because the terminal is not running. Moreover, the hotkey should be released for other programs to use in this case. This is how ConEmu and Terminator behave. * What happens when the user has multiple Terminal windows open? Which one opens? Does nothing happen in that case? If single instance setting is active: there can be no multiple windows open. If single instance setting is not active, Terminator sends the command to all instances and they all toggle states. This might be the simplest solution; it doesn't make much sense to use quake mode with multiple instances and this way terminals won't get permanently stuck in hidden state (terminator hides the window from the taskbar in hidden state). ConEmu: enabling quake mode enforces single instance mode and grays out the check box. This makes more sense behavior-wise, but introduces more complexity. I don't think the absence of single instance mode (#2227) should get in the way of implementing this functionality. * With multiple terminal windows open, and one terminal currently focused, does the global hotkey hide the active window, or summon a minimized one? See above - both. It toggles their states. * Can the user choose to have the window appear maximized? Fullscreen? In both ConEmu and Terminator this is not relevant to quake mode, the window gets restored into whatever state it was in before being toggled hidden. If it was full screen, it restores to full screen; same for maximized and non-maximized windows.

claunia commented

@zakius commented on GitHub (Nov 15, 2019):

just being a little nitpicky: none of popular terminals use actual (exclusive) fullscreen but can be rendered borderless

and I think it's much better for the usecase

@zakius commented on GitHub (Nov 15, 2019): just being a little nitpicky: none of popular terminals use actual (exclusive) fullscreen but can be rendered borderless and I think it's much better for the usecase

claunia commented

@pandasauce commented on GitHub (Nov 15, 2019):

From user's viewpoint, the main difference between "fullscreen" and windowed maximized seems to be that "fullscreen" covers the taskbar.
-------- Original message --------From: zakius notifications@github.com Date: 15/11/2019 22:38 (GMT+00:00) To: microsoft/terminal terminal@noreply.github.com Cc: Igroeg Okiob georgi@pandasauce.org, Comment comment@noreply.github.com Subject: Re: [microsoft/terminal] Feature request: hot key drop down ala
quake/guake/tilda (#653) just being a little nitpicky: none of popular terminals use actual (exclusive) fullscreen but can be rendered borderless
and I think it's much better for the usecase

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/microsoft/terminal/issues/653?email_source=notifications\u0026email_token=AB2TW7D3V347CBC62MCQ32TQT4QHVA5CNFSM4HL735C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEG5YSA#issuecomment-554556488",
"url": "https://github.com/microsoft/terminal/issues/653?email_source=notifications\u0026email_token=AB2TW7D3V347CBC62MCQ32TQT4QHVA5CNFSM4HL735C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEG5YSA#issuecomment-554556488",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]

@pandasauce commented on GitHub (Nov 15, 2019): From user's viewpoint, the main difference between "fullscreen" and windowed maximized seems to be that "fullscreen" covers the taskbar. -------- Original message --------From: zakius <notifications@github.com> Date: 15/11/2019 22:38 (GMT+00:00) To: microsoft/terminal <terminal@noreply.github.com> Cc: Igroeg Okiob <georgi@pandasauce.org>, Comment <comment@noreply.github.com> Subject: Re: [microsoft/terminal] Feature request: hot key drop down ala quake/guake/tilda (#653) just being a little nitpicky: none of popular terminals use actual (exclusive) fullscreen but can be rendered borderless and I think it's much better for the usecase —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe. [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/microsoft/terminal/issues/653?email_source=notifications\u0026email_token=AB2TW7D3V347CBC62MCQ32TQT4QHVA5CNFSM4HL735C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEG5YSA#issuecomment-554556488", "url": "https://github.com/microsoft/terminal/issues/653?email_source=notifications\u0026email_token=AB2TW7D3V347CBC62MCQ32TQT4QHVA5CNFSM4HL735C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEG5YSA#issuecomment-554556488", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

claunia commented

@bdwakefield commented on GitHub (Jan 3, 2020):

A Quake console style hotkey (ConEmu) is a must. Has anyone been able to attached Terminal to ConEmu?

@bdwakefield commented on GitHub (Jan 3, 2020): A Quake console style hotkey (ConEmu) is a must. Has anyone been able to attached Terminal to ConEmu?

claunia commented

2026-01-30 22:11:24 +00:00

@josefnorlin commented on GitHub (Feb 21, 2020):

@dotjosh That looks great! Is there any reason why you implemented that as a standalone tool and not a PR? How much effort would it be to merge it?

I'm strong in C#/WPF and I was able to get it done quickly. I'd be willing to help port it if we are happy with the behavior.

We are! Can we have this a pull-request?

@josefnorlin commented on GitHub (Feb 21, 2020): > > > > @dotjosh That looks great! Is there any reason why you implemented that as a standalone tool and not a PR? How much effort would it be to merge it? > > I'm strong in C#/WPF and I was able to get it done quickly. I'd be willing to help port it if we are happy with the behavior. We are! Can we have this a pull-request?

claunia commented

@zakius commented on GitHub (Mar 22, 2020):

For some people it's not important at all, for others it's a dealbreaker, though I'd be able to live without it thanks to some workarounds posted here so personally I'd prioritize things that can't be supplemented in any way like #574 (or likely many other, that's just my second dealbreaker)

@zakius commented on GitHub (Mar 22, 2020): For some people it's not important at all, for others it's a dealbreaker, though I'd be able to live without it thanks to some workarounds posted here so personally I'd prioritize things that can't be supplemented in any way like #574 (or likely many other, that's just my second dealbreaker)

claunia commented

2026-01-30 22:11:24 +00:00

@DHowett-MSFT commented on GitHub (Mar 22, 2020):

Right. You're talking about how we've failed to prioritize this appropriately, and I appreciate that this feature is important to you. I'd like to ask, however: with the four engineers on the core team, which of the features completed in the following milestones (scoped query, plus loose features) should we have cut to make room for custom window management?

Features marked Fix-Committed and closed
accessibility
tabs in the titlebar
panes
settings validation
profile detection
rationalized exit semantics
proper rendering for CJK ideographs
input support for non-US-ANSI keyboard users
resizing that doesn't delete your history
search
(i could continue to list features here)

I can commit engineering to one, maybe two features per dev per month. It's been 10 months, and in most of that time we've had a team of 2-3 instead of 4.

If you can identify which of those things that we decided were table stakes that we should have shipped without, I'm happy to have that discussion with you.

@DHowett-MSFT commented on GitHub (Mar 22, 2020): Right. You're talking about how we've failed to prioritize this appropriately, and I appreciate that this feature is important to you. I'd like to ask, however: with the four engineers on the core team, which of the features completed in the following milestones (scoped query, plus loose features) should we have cut to make room for custom window management? * _[Features marked Fix-Committed and closed](https://github.com/microsoft/terminal/issues?q=is%3Aclosed+is%3Aissue++label%3AIssue-Feature+label%3AResolution-Fix-Committed+)_ * accessibility * tabs in the titlebar * panes * settings validation * profile detection * rationalized exit semantics * proper rendering for CJK ideographs * input support for non-US-ANSI keyboard users * resizing that doesn't delete your history * search * (i could continue to list features here) I can commit engineering to one, maybe two features per dev per month. It's been 10 months, and in most of that time we've had a team of 2-3 instead of 4. If you can identify which of those things that we decided were table stakes that we should have shipped without, I'm happy to have that discussion with you.

claunia commented

2026-01-30 22:11:24 +00:00

@zadjii-msft commented on GitHub (Mar 23, 2020):

If this is such a low-hanging fruit, then I'd be happy to review a PR from a community member to address this feature 😉. As it currently stands, the dev team is in a feature-freeze and bug-fix/polish sprint for the next couple months. We'll certainly be looking at our backlog for tasks to start on once 1.0 lands, and I want to make it clear that the team understands this one is a popular ask.

@zadjii-msft commented on GitHub (Mar 23, 2020): If this is such a low-hanging fruit, then I'd be happy to review a PR from a community member to address this feature 😉. As it currently stands, the dev team is in a feature-freeze and bug-fix/polish sprint for the next couple months. We'll certainly be looking at our backlog for tasks to start on once 1.0 lands, and I want to make it clear that the team understands this one is a popular ask.

claunia commented

@SamHasler commented on GitHub (Mar 25, 2020):

pinning it to the taskbar and using Win+1 to access it is ok as a workaround (although I'm now using kimbirkelund autohotkey script from https://github.com/microsoft/terminal/issues/653#issuecomment-541408854). I don't think this should be a priority.

Perhaps someone could compile kimbirkelund or wizcas's script and provide a binary for those that don't want to instal autohotkey?

@SamHasler commented on GitHub (Mar 25, 2020): pinning it to the taskbar and using Win+1 to access it is ok as a workaround (although I'm now using kimbirkelund autohotkey script from https://github.com/microsoft/terminal/issues/653#issuecomment-541408854). I don't think this should be a priority. Perhaps someone could compile kimbirkelund or wizcas's script and provide a binary for those that don't want to instal autohotkey?

claunia commented

@zakius commented on GitHub (Mar 26, 2020):

there are much better workarounds than keeping it on Taskbar what is the exact thing we want to avoid, but as you said there are some so while it's important it's lower on the priority list than things that can't be supplemented with external tools

@zakius commented on GitHub (Mar 26, 2020): there are much better workarounds than keeping it on Taskbar what is the exact thing we want to avoid, but as you said there are some so while it's important it's lower on the priority list than things that can't be supplemented with external tools

claunia commented

@farzadmf commented on GitHub (Apr 9, 2020):

Adding my two cents to the discussion, my modified version of the AutoHotKey script provided by @kimbirkelund:

The hot-key is Ctrl + ~
Terminal is set to remain on top
One thing I thought could be useful was this: if you have your terminal open and you open a window while the terminal is being displayed, if you hide the terminal, it doesn't know about this "new window" and goes back to the old active one. I've been using it for a couple of hours and it seems to be working

UPDATE: I updated my script so that if you switch to another window (alt+tab) for example, it will switch to that window when you hide the terminal

Here's the script, hopefully it's useful for others 🙂:

#Persistent
SetBatchLines, -1
Process, Priority,, High

Gui +LastFound
hWnd := WinExist()

; Subscribe to win-create events to get the activated window
DllCall( "RegisterShellHookWindow", UInt,hWnd )
MsgNum := DllCall( "RegisterWindowMessage", Str,"SHELLHOOK" )
OnMessage(MsgNum, Func("OnWin"))
Return

OnWin(event, hwnd)
{
  ; WinGetClass, winClass, ahk_id %lParam%
  WinGetClass, winClass, ahk_id %hwnd%
  if (winClass = "CASCADIA_HOSTING_WINDOW_CLASS")
  {
    global activatedWindow
    activatedWindow = -1
  }
  else
  {
    ; 1 is HSHELL_WINDOOWCREATED
    ; 4 is HSHELL_WINDOWACTIVATED
    if (event == 1 || event & 4)
    {
      global activatedWindow
      activatedWindow = -1
      activatedWindow = %hwnd%
    }
  }
}

; Toggle windows terminal using Ctrl,`
^`::ToggleTerminal()

ShowAndPositionTerminal()
{
  WinShow ahk_class CASCADIA_HOSTING_WINDOW_CLASS
  WinActivate ahk_class CASCADIA_HOSTING_WINDOW_CLASS

  WinMove, ahk_class CASCADIA_HOSTING_WINDOW_CLASS,, -5, -10, A_ScreenWidth + 10, A_ScreenHeight * 0.7,
  Winset, AlwaysOnTop, On, A
}

ToggleTerminal()
{
  global activatedWindow
  WinMatcher := "ahk_class CASCADIA_HOSTING_WINDOW_CLASS"

  DetectHiddenWindows, On

  if WinExist(WinMatcher)
  {
    DetectHiddenWindows, Off

    if WinExist(WinMatcher)
    {
      ; Script sees it without detecting hidden windows, so..
      WinHide ahk_class CASCADIA_HOSTING_WINDOW_CLASS
      if activatedWindow > 0
      {
        WinActivate, ahk_id, %activatedWindow%
        activatedWindow = -1
      }
      else
      {
        Send !{Esc}
      }
    }
    ; Check if its hidden
    else if !WinExist(WinMatcher) || !WinActive(WinMatcher)
    {
      ShowAndPositionTerminal()
    }
  }
  else
  {
    Run "%SCOOP%\apps\windows-terminal\current\WindowsTerminal.exe"
    Sleep, 1000
    ShowAndPositionTerminal()
  }
}

@farzadmf commented on GitHub (Apr 9, 2020): Adding my two cents to the discussion, my modified version of the `AutoHotKey` script provided by @kimbirkelund: - The hot-key is `Ctrl + ~` - Terminal is set to remain on top - One thing I thought could be useful was this: if you have your terminal open and you open a window while the terminal is being displayed, if you hide the terminal, it doesn't know about this "new window" and goes back to the old active one. I've been using it for a couple of hours and it seems to be working --- UPDATE: I updated my script so that if you switch to another window (alt+tab) for example, it will switch to that window when you hide the terminal --- Here's the script, hopefully it's useful for others 🙂: ```autohotkey #Persistent SetBatchLines, -1 Process, Priority,, High Gui +LastFound hWnd := WinExist() ; Subscribe to win-create events to get the activated window DllCall( "RegisterShellHookWindow", UInt,hWnd ) MsgNum := DllCall( "RegisterWindowMessage", Str,"SHELLHOOK" ) OnMessage(MsgNum, Func("OnWin")) Return OnWin(event, hwnd) { ; WinGetClass, winClass, ahk_id %lParam% WinGetClass, winClass, ahk_id %hwnd% if (winClass = "CASCADIA_HOSTING_WINDOW_CLASS") { global activatedWindow activatedWindow = -1 } else { ; 1 is HSHELL_WINDOOWCREATED ; 4 is HSHELL_WINDOWACTIVATED if (event == 1 || event & 4) { global activatedWindow activatedWindow = -1 activatedWindow = %hwnd% } } } ; Toggle windows terminal using Ctrl,` ^`::ToggleTerminal() ShowAndPositionTerminal() { WinShow ahk_class CASCADIA_HOSTING_WINDOW_CLASS WinActivate ahk_class CASCADIA_HOSTING_WINDOW_CLASS WinMove, ahk_class CASCADIA_HOSTING_WINDOW_CLASS,, -5, -10, A_ScreenWidth + 10, A_ScreenHeight * 0.7, Winset, AlwaysOnTop, On, A } ToggleTerminal() { global activatedWindow WinMatcher := "ahk_class CASCADIA_HOSTING_WINDOW_CLASS" DetectHiddenWindows, On if WinExist(WinMatcher) { DetectHiddenWindows, Off if WinExist(WinMatcher) { ; Script sees it without detecting hidden windows, so.. WinHide ahk_class CASCADIA_HOSTING_WINDOW_CLASS if activatedWindow > 0 { WinActivate, ahk_id, %activatedWindow% activatedWindow = -1 } else { Send !{Esc} } } ; Check if its hidden else if !WinExist(WinMatcher) || !WinActive(WinMatcher) { ShowAndPositionTerminal() } } else { Run "%SCOOP%\apps\windows-terminal\current\WindowsTerminal.exe" Sleep, 1000 ShowAndPositionTerminal() } } ```

claunia commented

@chazt3n commented on GitHub (Apr 10, 2020):

@zadjii-msft does that mean a PR won't be merged for a couple/few months?
This was the first thing I googled when I installed the terminal - which also thank you so much for creating a real terminal. Super excited

@chazt3n commented on GitHub (Apr 10, 2020): @zadjii-msft does that mean a PR won't be merged for a couple/few months? This was the first thing I googled when I installed the terminal - which also thank you so much for creating a real terminal. Super excited

claunia commented

@zadjii-msft commented on GitHub (Apr 10, 2020):

@chazt3n We're pretty heads down on cleaning up some of our bug backlog for 1.0 right now. We're definitely not going to be merging any PRs for this until after we release 1.0 at this point, but this is definitely something we're thinking about pulling in to 2.0.

I can't really give any estimates on when any of those dates are at this point, mostly just "when it's done"

@zadjii-msft commented on GitHub (Apr 10, 2020): @chazt3n We're pretty heads down on cleaning up some of our bug backlog for 1.0 right now. We're _definitely_ not going to be merging any PRs for this until after we release 1.0 at this point, but this is definitely something we're thinking about pulling in to 2.0. I can't really give any estimates on when any of those dates are at this point, mostly just "when it's done"

claunia commented

@hajya commented on GitHub (Apr 27, 2020):

Sorry if this is already covered above as I didn't read the full thread in detail. From a behavior perspective; I think it would be best if we were allowed to chose between 'quake mode' or just foreground existing window/tabs on hot key.

I currently use another console platform which simply gives me a checkbox in the settings to 'foreground the application with Ctrl + ~' but it otherwise fully respects the size and state of my existing window.

This feature is a very very very very nice to have as often we have so many windows and the terminal window (given its almost always not full screen) can get lost in the background.

@hajya commented on GitHub (Apr 27, 2020): Sorry if this is already covered above as I didn't read the full thread in detail. From a behavior perspective; I think it would be best if we were allowed to chose between 'quake mode' or just foreground existing window/tabs on hot key. I currently use another console platform which simply gives me a checkbox in the settings to 'foreground the application with Ctrl + ~' but it otherwise fully respects the size and state of my existing window. This feature is a very very very very nice to have as often we have so many windows and the terminal window (given its almost always not full screen) can get lost in the background.

claunia commented

@Defcon0 commented on GitHub (Apr 28, 2020):

The most important part is that we don't just have the window scaled to the full width but retaining its title bar. The title bar must ne invisible as well.

@Defcon0 commented on GitHub (Apr 28, 2020): The most important part is that we don't just have the window scaled to the full width but retaining its title bar. The title bar must ne invisible as well.

claunia commented

@blasnier commented on GitHub (Apr 28, 2020):

Sorry if this is already covered above as I didn't read the full thread in detail. From a behavior perspective; I think it would be best if we were allowed to chose between 'quake mode' or just foreground existing window/tabs on hot key.

It got lost in the hidden items of the thread, but @flyingpie shared a C# program to add the quake style feature. You can find it here, and if you look at Toggler.cs on line 51 and 72 you should be able to modify its behavior so that it only brings the window on the foreground without modifying its size. I have not tried though.

@blasnier commented on GitHub (Apr 28, 2020): > Sorry if this is already covered above as I didn't read the full thread in detail. From a behavior perspective; I think it would be best if we were allowed to chose between 'quake mode' or just foreground existing window/tabs on hot key. > It got lost in the hidden items of the thread, but @flyingpie shared a C# program to add the quake style feature. You can find it [here](https://github.com/flyingpie/windows-terminal-quake), and if you look at [Toggler.cs](https://github.com/flyingpie/windows-terminal-quake/blob/master/windows-terminal-quake/Toggler.cs) on line 51 and 72 you should be able to modify its behavior so that it only brings the window on the foreground without modifying its size. I have not tried though.

claunia commented

@zakius commented on GitHub (Apr 28, 2020):

I switched to ahk approach after a while, one of main reasons being I don't have to use VS to build it, but after some fiddling I got really nice results, the basis for it is somewhere in this thread too

note that I use it for Messenger instead as WT misses few more things for me

@zakius commented on GitHub (Apr 28, 2020): I switched to ahk approach after a while, one of main reasons being I don't have to use VS to build it, but after some fiddling I got really nice results, the basis for it is somewhere in this thread too note that I use it for Messenger instead as WT misses few more things for me

claunia commented

@hansek commented on GitHub (Apr 28, 2020):

An alternative solution until there will be a native dropdown mode for Terminal. 😃

After a couple of weeks of usage I can recommend https://eugeny.github.io/terminus/

Nice terminal with aka "quake mode" (Settings > "Dock the terminal" set to Top and "Hotkeys" > "Toggl terminal window" to Ctrl-` ).

It's built on Electron so it's not a "lightweight", but works pretty smoothly with WSL2.

@hansek commented on GitHub (Apr 28, 2020): _An alternative solution until there will be a native dropdown mode for Terminal. 😃_ After a couple of weeks of usage I can recommend https://eugeny.github.io/terminus/ Nice terminal with aka "quake mode" (Settings > "Dock the terminal" set to `Top` and "Hotkeys" > "Toggl terminal window" to ``Ctrl-` ``). It's built on Electron so it's not a "lightweight", but works pretty smoothly with WSL2.

claunia commented

@chazt3n commented on GitHub (May 1, 2020):

I've enjoyed setting it to the first part of my task bar and using WIN + 1 to open it.

My only problem is I cannot always open it in admin which equals WSL being unusably gimped. SO right click, right click, open as admin - WIN + 1 from then on.

@chazt3n commented on GitHub (May 1, 2020): I've enjoyed setting it to the first part of my task bar and using WIN + 1 to open it. My only problem is I cannot always open it in admin which equals WSL being unusably gimped. SO right click, right click, open as admin - WIN + 1 from then on.

claunia commented

@SamHasler commented on GitHub (May 1, 2020):

@chazt3n If you want to open in admin using the keyboard it would be:
WIN+ALT+1 to open the right click menu for that taskbar item.
Menu Key (next to Right CTRL key) or SHIFT+F10
Pick "open as admin" with arrow keys and enter.

@SamHasler commented on GitHub (May 1, 2020): @chazt3n If you want to open in admin using the keyboard it would be: <kbd>WIN</kbd>+<kbd>ALT</kbd>+<kbd>1</kbd> to open the right click menu for that taskbar item. <kbd>Menu Key</kbd> (next to Right CTRL key) or <kbd>SHIFT</kbd>+<kbd>F10</kbd> Pick "open as admin" with arrow keys and enter.

claunia commented

@Jaykul commented on GitHub (May 4, 2020):

@chazt3n @SamHasler no need to do it the hard way.
If you hold Shift while open an app, you get a second copy.
If you hold Shift and Ctrl while you open an app it opens elevated.
That's true whether from the start menu, the run dialog, or the task bar, and whether you open it with the keyboard or by clicking...

In other words, mash down the whole corner of the keyboard before you press 1: Ctrl+Shift+Win+1 will open a new copy elevated.

@Jaykul commented on GitHub (May 4, 2020): @chazt3n @SamHasler no need to do it the hard way. If you hold Shift while open an app, you get a second copy. If you hold Shift **and** Ctrl while you open an app it opens elevated. _That's true whether from the start menu, the run dialog, or the task bar, and whether you open it with the keyboard or by clicking..._ In other words, mash down the whole corner of the keyboard before you press 1: Ctrl+Shift+Win+1 will open a new copy elevated.

claunia commented

@weitzhandler commented on GitHub (May 4, 2020):

Related: https://github.com/microsoft/PowerToys/issues/2629.

@weitzhandler commented on GitHub (May 4, 2020): Related: https://github.com/microsoft/PowerToys/issues/2629.

claunia commented

@oising commented on GitHub (May 4, 2020):

@Jaykul When I tell people about the magic elevator modifier, they always say "whattttt"

@oising commented on GitHub (May 4, 2020): @Jaykul When I tell people about the magic elevator modifier, they always say "whattttt"

claunia commented

https://github.com/usrcletus/winuake

@UsrCletus commented on GitHub (May 19, 2020):

I am actually working on a project like this and would love to collaborate with anyone interested in helping out. I should have an alpha release by the end of the weekend that supports CMD, powershell, and WSL with drop-down style functionality.

I am interested in expanding on guake/yakuake and what they did however with some additional ideas like NOFUNEVER described with being able to use multiple monitors at once but i'm not sure what that would look like.

This is NOT ready for testing yet but I should have an alpha ready for testing by the end of the weekend if anyone is interested in collaborating please mail me at mwayne.h@gmail.com. Someone who's good at theming apps and working with Controls in C# would be a big help.

Please be easy on me, it's in super rough stages lol.

@UsrCletus commented on GitHub (May 19, 2020): I am actually working on a project like this and would love to collaborate with anyone interested in helping out. I should have an alpha release by the end of the weekend that supports CMD, powershell, and WSL with drop-down style functionality. I am interested in expanding on guake/yakuake and what they did however with some additional ideas like NOFUNEVER described with being able to use multiple monitors at once but i'm not sure what that would look like. This is NOT ready for testing yet but I should have an alpha ready for testing by the end of the weekend if anyone is interested in collaborating please mail me at mwayne.h@gmail.com. Someone who's good at theming apps and working with Controls in C# would be a big help. https://github.com/usrcletus/winuake Please be easy on me, it's in super rough stages lol.

claunia commented

@TheBrigandier commented on GitHub (May 29, 2020):

Would love to see this functionality make it in. Extremely pleased with how Windows Terminal works (it's one of the few Windows terminal apps that don't choke and die on the "cmatrix" speed test!). Please include it (when you can :) ), once you're used to this functionality you can't live without it.

@TheBrigandier commented on GitHub (May 29, 2020): Would love to see this functionality make it in. Extremely pleased with how Windows Terminal works (it's one of the few Windows terminal apps that don't choke and die on the "cmatrix" speed test!). Please include it (when you can :) ), once you're used to this functionality you can't live without it.

claunia commented

@hd321kbps commented on GitHub (May 30, 2020):

This feature is very time saving.
Really looking forward to Windows Terminal 2.0

@hd321kbps commented on GitHub (May 30, 2020): This feature is very time saving. Really looking forward to Windows Terminal 2.0

claunia commented

@VintageCake commented on GitHub (Jun 7, 2020):

Very much watned feature, would really make the environment switch betwenn Linux and Windows a lot nicer.

@VintageCake commented on GitHub (Jun 7, 2020): Very much watned feature, would really make the environment switch betwenn Linux and Windows a lot nicer.

claunia commented

@zakius commented on GitHub (Jun 7, 2020):

Very much watned feature, would really make the environment switch betwenn Linux and Windows a lot nicer.

that would require some of Linux terminal emulators to have all conemu features, Windows already has it all

@zakius commented on GitHub (Jun 7, 2020): > Very much watned feature, would really make the environment switch betwenn Linux and Windows a lot nicer. that would require some of Linux terminal emulators to have all conemu features, Windows already has it all

claunia commented

@Defcon0 commented on GitHub (Jun 11, 2020):

The team released a roadmap and this issue is in there 🥳 Although it has priority 3 in a scale from 0 to 2 😢

@Defcon0 commented on GitHub (Jun 11, 2020): The team released a roadmap and this issue is in there 🥳 Although it has priority 3 in a scale from 0 to 2 😢

claunia commented

@DHowett commented on GitHub (Jun 11, 2020):

Sorry, our scale actually does go to 3. Whoops! 😄

@DHowett commented on GitHub (Jun 11, 2020): Sorry, our scale actually does go to 3. Whoops! :smile:

claunia commented

@Defcon0 commented on GitHub (Jun 11, 2020):

Nevertheless it seems that this issues might not make it even into the release in 1 year. Too bad. I was very keen to use the new terminal but without the hot key feature it’s too cumbersome compared to guake on linux.

@Defcon0 commented on GitHub (Jun 11, 2020): Nevertheless it seems that this issues might not make it even into the release in 1 year. Too bad. I was very keen to use the new terminal but without the hot key feature it’s too cumbersome compared to guake on linux.

claunia commented

@TheBrigandier commented on GitHub (Jun 11, 2020):

Happy it made the list at least. :) - WSL2 Docker has made Windows a more doable daily driver, this feature will just push it further when it lands.

@TheBrigandier commented on GitHub (Jun 11, 2020): Happy it made the list at least. :) - WSL2 Docker has made Windows a more doable daily driver, this feature will just push it further when it lands.

claunia commented

@eggeek commented on GitHub (Jun 12, 2020):

I agree that this is a handy feature, and I would really need this if I use Windows.
However, all mentioned functionalities should be handled by the window manager, instead of a terminal.

@eggeek commented on GitHub (Jun 12, 2020): I agree that this is a handy feature, and I would really need this if I use Windows. However, all mentioned functionalities should be handled by the window manager, instead of a terminal.

claunia commented

@zakius commented on GitHub (Jun 12, 2020):

Technically that would be optimal if WM allowed that, you'd be able to handle all and every window with ease but it's unlikely we'll get that soon. The best bet would be adding that to PowerToys

@zakius commented on GitHub (Jun 12, 2020): Technically that would be optimal if WM allowed that, you'd be able to handle all and every window with ease but it's unlikely we'll get that soon. The best bet would be adding that to PowerToys

claunia commented

@oising commented on GitHub (Jun 12, 2020):

Not neccessarily. It just means that Microsoft staff won't work on it.
Anyone can submit the feature as a PR.

@oising commented on GitHub (Jun 12, 2020): Not neccessarily. It just means that Microsoft staff won't work on it. Anyone can submit the feature as a PR.

claunia commented

@humanfactors commented on GitHub (Jun 15, 2020):

If anybody wants a very simple AutoHotkey solution, see gist: https://gist.github.com/atruskie/99a498ac43b91deb91eab4069b6047b9

It's not the exact solution, but it does the job without much effort.

#NoEnv
#SingleInstance force
SendMode Input
DetectHiddenWindows, on
SetWinDelay, 0

#`::
    terminal := WinExist("ahk_exe WindowsTerminal.exe")
    if (terminal) 
    {
        active := WinActive("ahk_id " terminal)
        if (active)
            WinMinimize, ahk_id %active%
        else
            WinActivate, ahk_id %terminal%
    }
    else
        Run, wt.exe
Return

@humanfactors commented on GitHub (Jun 15, 2020): If anybody wants a very simple AutoHotkey solution, see gist: https://gist.github.com/atruskie/99a498ac43b91deb91eab4069b6047b9 It's not the exact solution, but it does the job without much effort. ```AHK #NoEnv #SingleInstance force SendMode Input DetectHiddenWindows, on SetWinDelay, 0 #`:: terminal := WinExist("ahk_exe WindowsTerminal.exe") if (terminal) { active := WinActive("ahk_id " terminal) if (active) WinMinimize, ahk_id %active% else WinActivate, ahk_id %terminal% } else Run, wt.exe Return ```

claunia commented

@chazt3n commented on GitHub (Jun 15, 2020):

@Defcon0 I just put it as the first entry in my task bar and use WIN + 1, it's honestly a little more convenient for me since I can place it anywhere on the screen.

@Jaykul provided one step opening in admin as well

@chazt3n commented on GitHub (Jun 15, 2020): @Defcon0 I just put it as the first entry in my task bar and use WIN + 1, it's honestly a little more convenient for me since I can place it anywhere on the screen. @Jaykul provided one step opening in admin as well

claunia commented

@sharunkumar commented on GitHub (Jun 16, 2020):

If anybody wants a very simple AutoHotkey solution, see gist: https://gist.github.com/atruskie/99a498ac43b91deb91eab4069b6047b9

It's not the exact solution, but it does the job without much effort.

#NoEnv
#SingleInstance force
SendMode Input
DetectHiddenWindows, on
SetWinDelay, 0

#`::
    terminal := WinExist("ahk_exe WindowsTerminal.exe")
    if (terminal) 
    {
        active := WinActive("ahk_id " terminal)
        if (active)
            WinMinimize, ahk_id %active%
        else
            WinActivate, ahk_id %terminal%
    }
    else
        Run, wt.exe
Return

I wrote a gist like this a while ago: https://gist.github.com/sharunkumar/af7ba56e3cce8238ae9c986c619e8d1c

this one switches back to the active window which you were in, before you switched to WT

global PreviousActiveWindow

#`::
DetectHiddenWindows, On
if (WinExist("ahk_class CASCADIA_HOSTING_WINDOW_CLASS")) {
	if(WinActive("ahk_class CASCADIA_HOSTING_WINDOW_CLASS")) {
		WinActivate, ahk_id %PreviousActiveWindow%
	} else {
		WinGet, PreviousActiveWindow, , A ; 'A' for currently active window
		WinActivate, ahk_class CASCADIA_HOSTING_WINDOW_CLASS
	}
} else {
	TerminalLink = %localappdata%\Microsoft\WindowsApps\wt.exe
	if FileExist(TerminalLink) {
		WinGet, PreviousActiveWindow, , A ; 'A' for currently active window
		Run, %TerminalLink%
	} else {
		MsgBox, Windows Terminal not installed
	}
}
Return

@sharunkumar commented on GitHub (Jun 16, 2020): > If anybody wants a very simple AutoHotkey solution, see gist: https://gist.github.com/atruskie/99a498ac43b91deb91eab4069b6047b9 > > It's not the exact solution, but it does the job without much effort. > > ```ahk > #NoEnv > #SingleInstance force > SendMode Input > DetectHiddenWindows, on > SetWinDelay, 0 > > #`:: > terminal := WinExist("ahk_exe WindowsTerminal.exe") > if (terminal) > { > active := WinActive("ahk_id " terminal) > if (active) > WinMinimize, ahk_id %active% > else > WinActivate, ahk_id %terminal% > } > else > Run, wt.exe > Return > ``` I wrote a gist like this a while ago: https://gist.github.com/sharunkumar/af7ba56e3cce8238ae9c986c619e8d1c this one switches back to the active window which you were in, before you switched to WT ```ahk global PreviousActiveWindow #`:: DetectHiddenWindows, On if (WinExist("ahk_class CASCADIA_HOSTING_WINDOW_CLASS")) { if(WinActive("ahk_class CASCADIA_HOSTING_WINDOW_CLASS")) { WinActivate, ahk_id %PreviousActiveWindow% } else { WinGet, PreviousActiveWindow, , A ; 'A' for currently active window WinActivate, ahk_class CASCADIA_HOSTING_WINDOW_CLASS } } else { TerminalLink = %localappdata%\Microsoft\WindowsApps\wt.exe if FileExist(TerminalLink) { WinGet, PreviousActiveWindow, , A ; 'A' for currently active window Run, %TerminalLink% } else { MsgBox, Windows Terminal not installed } } Return ```

claunia commented

@Belphemur commented on GitHub (Jun 19, 2020):

I found this repository for a simple app that add quake to the terminal:
https://github.com/flyingpie/windows-terminal-quake

Works well enough for my use cases.

@Belphemur commented on GitHub (Jun 19, 2020): I found this repository for a simple app that add quake to the terminal: https://github.com/flyingpie/windows-terminal-quake Works well enough for my use cases.

claunia commented

@mattscully commented on GitHub (Jun 23, 2020):

I found this can be easily achieved using the Keyboard Manager PowerToy and the aforementioned Windows Key + NUM shortcut to launch an application pinned to your taskbar. Simply pin the Windows Terminal to your task bar (mine is in position 6) and then open the PowerToys Keyboard Manager tool. I have used WIN + ` with Cmder and so remapped the shortcut WIN + ` to WIN + 6. Now, whenever I do WIN + ` the Windows Terminal will come to the front or will launch a new instance if it's not already running (which is even better than what Cmder does natively).

@mattscully commented on GitHub (Jun 23, 2020): I found this can be easily achieved using the [Keyboard Manager PowerToy](https://github.com/microsoft/PowerToys/wiki/Keyboard-Manager-Overview) and the aforementioned Windows Key + NUM shortcut to launch an application pinned to your taskbar. Simply pin the Windows Terminal to your task bar (mine is in position 6) and then open the PowerToys Keyboard Manager tool. I have used ``WIN + ` `` with Cmder and so _remapped_ the shortcut ``WIN + ` `` to `WIN + 6`. Now, whenever I do ``WIN + ` `` the Windows Terminal will come to the front or will launch a new instance if it's not already running (which is even better than what Cmder does natively). ![image](https://user-images.githubusercontent.com/1304969/85343166-c6752b00-b4b1-11ea-90da-ed7188672407.png)

claunia commented

@zakius commented on GitHub (Jun 23, 2020):

no, it's not the same thing
minimize != hide window
window hiding makes it get out of your way completely

@zakius commented on GitHub (Jun 23, 2020): no, it's not the same thing minimize != hide window window hiding makes it get out of your way completely

claunia commented

@mattscully commented on GitHub (Jun 23, 2020):

You are correct, this is certainly not quake mode--sorry for any confusion. I found this issue just looking for a way to have a custom global shortcut bring the Terminal to the foreground which was a deal breaker for me as I'm used to that behavior from Cmder. Personally, I haven't felt a need for Quake mode so this shortcut solution filled the gap and so I thought I would pass it along.

@mattscully commented on GitHub (Jun 23, 2020): You are correct, this is certainly not quake mode--sorry for any confusion. I found this issue just looking for a way to have a custom global shortcut bring the Terminal to the foreground which was a deal breaker for me as I'm used to that behavior from Cmder. Personally, I haven't felt a need for Quake mode so this shortcut solution filled the gap and so I thought I would pass it along.

claunia commented

@nofunatall commented on GitHub (Jul 3, 2020):

This is the most upvoted feature request and has been open for over a year??

How the hell is this not implemented yet?

@nofunatall commented on GitHub (Jul 3, 2020): This is the most upvoted feature request and has been open for over a year?? How the hell is this not implemented yet?

claunia commented

@zadjii-msft commented on GitHub (Jul 20, 2020):

Hey I'm just posting some research notes here, because I don't want to lose them.

RegisterHotKey didn't seem to do anything in my experimentation. Maybe I was doing it wrong? Maybe the XAML Island is eating the WM_HOTKEY message before it even gets to our wndproc? There doesn't seem to be any feedback on that function anyways, so I'm not sure how helpful that is in a "multi instance mode".

SendMessage(_window.get(), WM_SETHOTKEY, VK_OEM_3, 0) actually did work. It even returns 2 if there's another window with that hotkey already set, which is nice. That'll do everything for us - when the key is pressed anywhere on the system, it'll activate the Terminal window, even if it's minimized. Unsure about "minimized to taskbar", but progress is progress.

Unfortunately, it's not trivial to have a second Terminal Window wait for the first window to close, and then have it pick up the hotkey. Plus, who gets the hotkey if there are 3 opened WT windows? So right now, only the first window would get the hotkey assigned to it, and then any subsequent windows created wouldn't get the hotkey assigned to them, until the first window is closed. Then, the next WT window created would get the hotkey. That's certainly awkward.

Settings reloading would probably also result in a random WT window getting the hotkey assigned.

There's a bunch of asks in this thread, so I'm gonna try and summarize them, but not prescribe a holistic solution yet.

Press a hotkey anywhere to activate the single Terminal window wherever it was (requires single-instance mode, as well as global hotkey support)
Press a hotkey anywhere to activate the single Terminal window on the current monitor. If it wasn't previously on that monitor, move it there. (requires single-instance mode, as well as global hotkey support)
Press a hotkey to activate the "nearest" terminal window. (This will probably require some IPC like what #5000 is working on)
Minimize to tray, press a hotkey to activate the single terminal window / the nearest terminal window (#5727)
Terminal doesn't appear in alt+tab view, press a hotkey to activate the single terminal window / the nearest terminal window (I'm not sure this is distinct from the above
when the Terminal is summoned using the hotkey, have it "slide in" from the top (Unsure if this is possible with the SendMessage(WM_SETHOTKEY) method above.)
- Similarly, slide out on deactivate?

Wow I'm sure that I missed some of the scenarios covered in the 95 comments on this thread, but already that's a mess of settings.

EDIT 17-Aug-2020: Oh hey this is how PowerToys hooks the keyboard for global messages, lets just do that.
49b56d9b52/src/modules/shortcut_guide/shortcut_guide.cpp (L150-L173)

@zadjii-msft commented on GitHub (Jul 20, 2020): Hey I'm just posting some research notes here, because I don't want to lose them. [`RegisterHotKey`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-registerhotkey) didn't seem to do anything in my experimentation. Maybe I was doing it wrong? Maybe the XAML Island is eating the `WM_HOTKEY` message before it even gets to our wndproc? There doesn't seem to be any feedback on that function anyways, so I'm not sure how helpful that is in a "multi instance mode". [`SendMessage(_window.get(), WM_SETHOTKEY, VK_OEM_3, 0)`](https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-sethotkey) actually _did_ work. It even returns `2` if there's another window with that hotkey already set, which is nice. That'll do everything for us - when the key is pressed _anywhere_ on the system, it'll activate the Terminal window, even if it's minimized. Unsure about "minimized to taskbar", but progress is progress. Unfortunately, it's not trivial to have a second Terminal Window wait for the first window to close, and then have it pick up the hotkey. Plus, who gets the hotkey if there are 3 opened WT windows? So right now, only the first window would get the hotkey assigned to it, and then any subsequent windows created _wouldn't_ get the hotkey assigned to them, until the first window is closed. Then, the _next WT window created_ would get the hotkey. That's certainly awkward. Settings reloading would probably also result in a _random_ WT window getting the hotkey assigned. There's a bunch of asks in this thread, so I'm gonna try and summarize them, but not prescribe a holistic solution yet. * Press a hotkey anywhere to activate the single Terminal window wherever it was (requires single-instance mode, as well as global hotkey support) * Press a hotkey anywhere to activate the single Terminal window _on the current monitor_. If it wasn't previously on that monitor, move it there. (requires single-instance mode, as well as global hotkey support) * Press a hotkey to activate the "nearest" terminal window. (This will probably require some IPC like what #5000 is working on) * Minimize to tray, press a hotkey to activate the single terminal window / the nearest terminal window (#5727) * Terminal doesn't appear in alt+tab view, press a hotkey to activate the single terminal window / the nearest terminal window (I'm not sure this is distinct from the above * when the Terminal is summoned using the hotkey, have it "slide in" from the top (Unsure if this is possible with the `SendMessage(WM_SETHOTKEY)` method above.) - Similarly, slide out on deactivate? Wow I'm sure that I missed some of the scenarios covered in the 95 comments on this thread, but already that's a mess of settings. <hr> EDIT 17-Aug-2020: Oh hey this is how PowerToys hooks the keyboard for global messages, lets just do that. https://github.com/microsoft/PowerToys/blob/49b56d9b52bdfedd6ad1404bd0b20e884d2b574b/src/modules/shortcut_guide/shortcut_guide.cpp#L150-L173

claunia commented

@Croydon commented on GitHub (Jul 27, 2020):

In my humble opinion minimizing to tray sounds like a different feature.

Having multi-instances and having different instances summoned on different displays sounds like something for a second iteration of this feature.

I think it would be better to first concentrate on simpler scenarios, like a single instance being summoned via slide-in on a hotkey and slide-out on the same hotkey. If there are multi-instances there should be probably a rule which one gets summoned then

@Croydon commented on GitHub (Jul 27, 2020): In my humble opinion minimizing to tray sounds like a different feature. Having multi-instances and having different instances summoned on different displays sounds like something for a second iteration of this feature. I think it would be better to first concentrate on simpler scenarios, like a single instance being summoned via slide-in on a hotkey and slide-out on the same hotkey. If there are multi-instances there should be probably a rule which one gets summoned then

claunia commented

2026-01-30 22:11:33 +00:00

@markkrj commented on GitHub (Aug 9, 2020):

IMO, as WT has multiple tabs, best scenario is one instance and get summoned where mouse is, if there are multiple virtual desktops or monitors. Like Guake.

@markkrj commented on GitHub (Aug 9, 2020): IMO, as WT has multiple tabs, best scenario is one instance and get summoned where mouse is, if there are multiple virtual desktops or monitors. Like Guake.

claunia commented

@jelster commented on GitHub (Aug 27, 2020):

Hi @zadjii-msft -- I have been looking at some similar areas as well and I wanted to consolidate the research along with sharing some implementations thoughts. Reading through the materials, I couldn't be sure if I was missing where the team's looked at ways to leverage UAP/UWP features that might be relevant so hopefully this isn't already-trodden ground!

First off, the hot key registration. I found the WM_HOTKEY research you did complementary to this UWP hotkey registration route outlined here. Is this an approach you've already considered? I thought it could be a nice approach, since the "launch windows terminal here" explorer context menu has already been implemented, removing the need to build/test the AppService/IPC (#5000) since we could simply extend and enhance what's already there.

While digging into this, I came across this possibly relevant SO answer outlining an approaching that attaches to the Windows.UI.Core.CoreDispatcher.AcceleratorKeyActivated in order to receive notifications when special key combos are pressed e.g., CTRL+~. Is this something that might be applicable?

Speaking of the process model...

Unfortunately, it's not trivial to have a second Terminal Window wait for the first window to close, and then have it pick up the hotkey. Plus, who gets the hotkey if there are 3 opened WT windows? So right now, only the first window would get the hotkey assigned to it, and then any subsequent windows created wouldn't get the hotkey assigned to them, until the first window is closed. Then, the next WT window created would get the hotkey. That's certainly awkward.
Settings reloading would probably also result in a random WT window getting the hotkey assigned.

There's a common thread with these challenges that, once plucked out of the equation makes things much more clear and simple. That common thread is the logic and complexity involved in wt instance management - I think that much of the rest is fallout from that core challenge. Like many challenges, this one might be best solved by breaking it down into smaller challenges. Here, I think that introducing an intermediary makes it unnecessary for WT to need to know anything about instance management, let alone handling global (e.g., application isn't in focus) hot key registration and binding. This appeals to me from the SRP standpoint, and it seems to me that the work to provide the "launch Windows Terminal Here" explorer context menu aligns with this conceptually, if not in reality. The UWP desktop extensions' TriggerEvent can be used by IPC services to pass serialized Actions (commands) to running wt instances or parsed and passed as launch args for new wt processes

The process handling the global hotkey would be both a system tray application and be a single-instance mode process (likely a WinForms app) that contains a NotifyIcon component along with the system tray icon's context menu and dispatcher components. This has a positive side-effect of obviating the need to add a lot of new and complicated settings+logic to the WT codebase, since wt won't need to know anything about a so-called "quake mode" 😄. The systray application would be the source/repository for these types of settings, and which I think will absolutely work with and benefit from #7170

Press a hotkey anywhere to activate the single Terminal window wherever it was (requires single-instance mode, as well as global hotkey support)

The systray app's context menu could have a flyout that displays a list of wt profiles that users can click to select the profile to use when invoked "in the style of Quake Mode". It might default to the first profile listed if unspecified. If there are plans/specs for implementing internal logic for getting lists of profiles and their details, the design would benefit from the ability to be used outside of the wt.exe process (as in, the notifyicon application shouldn't have to duplicate functionality to load the list of profiles and such if at all possible). Because the systray app manages instances, wt does not necessarily need to implement single-instance mode itself. The PowerToys repos shows the UWP IPC decls in the manifest and likely has more useful nuggets.

Summing up an already info-dense post:

Most of the bulleted concerns disappear or are greatly mitigated with this approach if you think about it. When I take a step back and look at the whole, I feel that this feature is closer to becoming a reality this than we thought!

Press a hotkey anywhere to activate the single Terminal window on the current monitor. If it wasn't previously on that monitor, move it there. (requires single-instance mode, as well as global hotkey support)

Press a hotkey to activate the "nearest" terminal window. (This will probably require some IPC like what #5000 is working on)

Minimize to tray, press a hotkey to activate the single terminal window / the nearest terminal window (#5727)

Terminal doesn't appear in alt+tab view, press a hotkey to activate the single terminal window / the nearest terminal window (I'm not sure this is distinct from the above

when the Terminal is summoned using the hotkey, have it "slide in" from the top (Unsure if this is possible with the SendMessage(WM_SETHOTKEY) method above.)

Similarly, slide out on deactivate?

Resources for NotifyIcon, WinForms, and WPF:
http://www.abhisheksur.com/2012/08/notifyicon-with-wpf-applications.html
https://www.codeproject.com/articles/36788/wpf-xaml-notifyicon-and-taskbar-system-tray-popup
https://mcguirev10.com/2019/01/27/system-tray-icons-wpf-net-core-preview.html

HTH!

EDIT:
Reading through the draft process model specs, it seems you have also identified the separate process approach. I suppose that the part of the "monarch" could in part or maybe(?) in whole played by the IPC/appservice

@jelster commented on GitHub (Aug 27, 2020): Hi @zadjii-msft -- I have been looking at some similar areas as well and I wanted to consolidate the research along with sharing some implementations thoughts. Reading through the materials, I couldn't be sure if I was missing where the team's looked at ways to leverage UAP/UWP features that might be relevant so hopefully this isn't already-trodden ground! First off, the hot key registration. I found the WM_HOTKEY research you did complementary to this UWP hotkey registration route outlined [here](https://stefanwick.com/2018/05/15/global-hotkey-registration-in-uwp/). Is this an approach you've already considered? I thought it could be a nice approach, since the "launch windows terminal here" explorer context menu has already been implemented, removing the need to build/test the AppService/IPC (#5000) since we could simply extend and enhance what's already there. While digging into this, I came across [this ](https://stackoverflow.com/a/39929167/105566) possibly relevant SO answer outlining an approaching that attaches to the Windows.UI.Core.CoreDispatcher.AcceleratorKeyActivated in order to receive notifications when special key combos are pressed e.g., `CTRL+~`. Is this something that might be applicable? Speaking of the process model... > Unfortunately, it's not trivial to have a second Terminal Window wait for the first window to close, and then have it pick up the hotkey. Plus, who gets the hotkey if there are 3 opened WT windows? So right now, only the first window would get the hotkey assigned to it, and then any subsequent windows created _wouldn't_ get the hotkey assigned to them, until the first window is closed. Then, the _next WT window created_ would get the hotkey. That's certainly awkward. > Settings reloading would probably also result in a _random_ WT window getting the hotkey assigned. There's a common thread with these challenges that, once plucked out of the equation makes things much more clear and simple. That common thread is the logic and complexity involved in wt instance management - I think that much of the rest is fallout from that core challenge. Like many challenges, this one might be best solved by breaking it down into smaller challenges. Here, I think that introducing an intermediary makes it unnecessary for WT to need to know anything about instance management, let alone handling global (e.g., application isn't in focus) hot key registration and binding. This appeals to me from the SRP standpoint, and it seems to me that the work to provide the "launch Windows Terminal Here" explorer context menu aligns with this conceptually, if not in reality. The UWP desktop extensions' [TriggerEvent ](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop6-triggerevents) can be used by IPC services to pass serialized Actions (commands) to running wt instances or parsed and passed as launch args for new wt processes The process handling the global hotkey would be both a system tray application _and_ be a single-instance mode process (likely a WinForms app) that contains a NotifyIcon component along with the system tray icon's context menu and dispatcher components. This has a positive side-effect of obviating the need to add a lot of new and complicated settings+logic to the WT codebase, since wt won't need to know anything about a so-called "quake mode" :smile:. The systray application would be the source/repository for these types of settings, and which I think will absolutely work with and benefit from #7170 > * Press a hotkey anywhere to activate the single Terminal window wherever it was (requires single-instance mode, as well as global hotkey support) The systray app's context menu could have a flyout that displays a list of wt profiles that users can click to select the profile to use when invoked "in the style of Quake Mode". It might default to the first profile listed if unspecified. If there are plans/specs for implementing internal logic for getting lists of profiles and their details, the design would benefit from the ability to be used outside of the wt.exe process (as in, the notifyicon application shouldn't have to duplicate functionality to load the list of profiles and such if at all possible). Because the systray app manages instances, wt does not necessarily need to implement single-instance mode itself. The PowerToys repos shows the [UWP IPC decls in the manifest](https://github.com/microsoft/PowerToys/blob/40a4a6a1a83d701c86d75f8bfb9bee540d9ef00a/installer/MSIX/appxmanifest.xml#L99) and likely has more useful nuggets. Summing up an already info-dense post: Most of the bulleted concerns disappear or are greatly mitigated with this approach if you think about it. When I take a step back and look at the whole, I feel that this feature is closer to becoming a reality this than we thought! > * Press a hotkey anywhere to activate the single Terminal window _on the current monitor_. If it wasn't previously on that monitor, move it there. (requires single-instance mode, as well as global hotkey support) > * Press a hotkey to activate the "nearest" terminal window. (This will probably require some IPC like what #5000 is working on) > * Minimize to tray, press a hotkey to activate the single terminal window / the nearest terminal window (#5727) > * Terminal doesn't appear in alt+tab view, press a hotkey to activate the single terminal window / the nearest terminal window (I'm not sure this is distinct from the above > * when the Terminal is summoned using the hotkey, have it "slide in" from the top (Unsure if this is possible with the `SendMessage(WM_SETHOTKEY)` method above.) > > * Similarly, slide out on deactivate? Resources for NotifyIcon, WinForms, and WPF: http://www.abhisheksur.com/2012/08/notifyicon-with-wpf-applications.html https://www.codeproject.com/articles/36788/wpf-xaml-notifyicon-and-taskbar-system-tray-popup https://mcguirev10.com/2019/01/27/system-tray-icons-wpf-net-core-preview.html HTH! EDIT: Reading through the draft process model specs, it seems you have also identified the [separate process approach](https://github.com/microsoft/terminal/pull/7240/files#diff-60da254e226652f9157b744e5f7162a5R538). I suppose that the part of the "monarch" could in part or maybe(?) in whole played by the IPC/appservice

claunia commented

2026-01-30 22:11:33 +00:00

@Inndy commented on GitHub (Aug 28, 2020):

I made a quick&dirty utility that register global hotkey to toggle last Windows Terminal window. I think it would be a nice workaround before official implementation.

https://github.com/Inndy/TerminalSummoner

@Inndy commented on GitHub (Aug 28, 2020): I made a quick&dirty utility that register global hotkey to toggle last Windows Terminal window. I think it would be a nice workaround before official implementation. https://github.com/Inndy/TerminalSummoner

claunia commented

2026-01-30 22:11:33 +00:00

@rengler33 commented on GitHub (Sep 19, 2020):

I modified an autohotkey solution from https://github.com/ehpc/quake-windows-bash for a little better user experience. I haven't looked into @Inndy 's solution so it may be better.

My script is located here: https://github.com/rengler33/dotfiles/blob/master/C/Users/Rub/wt-quake-like.ahk

Using the hotkey Ctrl + `

If windows terminal is not launched, it launches it*
If it's launched but minimized, it's restored
If it's active, it gets minimized
Otherwise (meaning it's restored but out of focus), bring it into focus

*Note: this script also uses a Windows shortcut that I like to use that adds a few options on opening
https://github.com/rengler33/dotfiles/blob/master/C/Users/Rub/wt.exe.lnk
But could be replaced to simply launch BashHandle instead instead of Shortcut

@rengler33 commented on GitHub (Sep 19, 2020): I modified an autohotkey solution from https://github.com/ehpc/quake-windows-bash for a little better user experience. I haven't looked into @Inndy 's solution so it may be better. My script is located here: https://github.com/rengler33/dotfiles/blob/master/C/Users/Rub/wt-quake-like.ahk Using the hotkey Ctrl + ` 1. If windows terminal is not launched, it launches it* 2. If it's launched but minimized, it's restored 3. If it's active, it gets minimized 4. Otherwise (meaning it's restored but out of focus), bring it into focus *Note: this script also uses a Windows shortcut that I like to use that adds a few options on opening https://github.com/rengler33/dotfiles/blob/master/C/Users/Rub/wt.exe.lnk But could be replaced to simply launch `BashHandle` instead instead of `Shortcut`

claunia commented

@oryon-dominik commented on GitHub (Sep 21, 2020):

I modified an autohotkey solution from https://github.com/ehpc/quake-windows-bash

Thanks for that.

I got inspired by @rengler33 's script and did some modifications for my own 3-screen setup:
https://gist.github.com/oryon-dominik/562970f77f2ad4d9bd57bea58ddc8ef5
The script spawns a Windows-Terminal on the active screen. (CTRL+CIRCUMFLEX)
Bad animations and a bit of flickering though, so it's more of a workaround.

I'm really looking forward to get this feature officially implemented..

@oryon-dominik commented on GitHub (Sep 21, 2020): > I modified an autohotkey solution from https://github.com/ehpc/quake-windows-bash Thanks for that. I got inspired by @rengler33 's script and did some modifications for my own 3-screen setup: https://gist.github.com/oryon-dominik/562970f77f2ad4d9bd57bea58ddc8ef5 The script spawns a Windows-Terminal on the active screen. (CTRL+CIRCUMFLEX) Bad animations and a bit of flickering though, so it's more of a workaround. I'm really looking forward to get this feature officially implemented..

claunia commented

@rzym-on commented on GitHub (Oct 5, 2020):

I also wanted to switch from ConEmu to Windows Terminal, but I was missing Quake Style too. If anyone is interested - I created a small app, that stores and pulls windows terminal window (you can add other apps to have this Quake Style if you want to).

Check my repo and all features here: https://github.com/rzym-on/termial-tray

I really hope, that this feature will come by default at some time. For now, feel free to use my little solution.

@rzym-on commented on GitHub (Oct 5, 2020): I also wanted to switch from ConEmu to Windows Terminal, but I was missing Quake Style too. If anyone is interested - I created a small app, that stores and pulls windows terminal window (you can add other apps to have this Quake Style if you want to). Check my repo and all features here: https://github.com/rzym-on/termial-tray I really hope, that this feature will come by default at some time. For now, feel free to use my little solution.

claunia commented

@mkanet commented on GitHub (Oct 5, 2020):

I also wanted to switch from ConEmu to Windows Terminal, but I was missing Quake Style too. If anyone is interested - I created a small app, that stores and pulls windows terminal window (you can add other apps to have this Quake Style if you want to).

Check my repo and all features here: https://github.com/rzym-on/termial-tray

I really hope, that this feature will come by default at some time. For now, feel free to use my little solution.

Thank you for this. Is there a way to adjust the animation speed of Windows Terminal window appearing.. the same way ConEmu does?

@mkanet commented on GitHub (Oct 5, 2020): > I also wanted to switch from ConEmu to Windows Terminal, but I was missing Quake Style too. If anyone is interested - I created a small app, that stores and pulls windows terminal window (you can add other apps to have this Quake Style if you want to). > > Check my repo and all features here: https://github.com/rzym-on/termial-tray > > I really hope, that this feature will come by default at some time. For now, feel free to use my little solution. Thank you for this. Is there a way to adjust the animation speed of Windows Terminal window appearing.. the same way ConEmu does?

claunia commented

@zadjii-msft commented on GitHub (Oct 5, 2020):

@mkanet I'd like to redirect discussion about someone else's project to their repo, and keep this thread focused on the issue at hand. Thanks!

@zadjii-msft commented on GitHub (Oct 5, 2020): @mkanet I'd like to redirect discussion about someone else's project to [their repo](https://github.com/rzym-on/termial-tray), and keep this thread focused on the issue at hand. Thanks!

claunia commented

@nicholasp commented on GitHub (Nov 24, 2020):

Another idea it could be a parameter to command wt.exe like: -T, --toggle
If instance of terminal not exists open a new
Else (If active minimize Else restore/activate)

Its like the AutoHotKey logic above but its inside wt.exe and accessible to .lnk shortcuts / global key mappings / windows taskbar Win+Number etc

It would be awesome if you don't need another 3rd party app for this. And I am also addicted to Ctrl+`

@nicholasp commented on GitHub (Nov 24, 2020): Another idea it could be a parameter to command wt.exe like: -T, --toggle If instance of terminal not exists open a new Else (If active minimize Else restore/activate) Its like the AutoHotKey logic above but its inside wt.exe and accessible to .lnk shortcuts / global key mappings / windows taskbar Win+Number etc It would be awesome if you don't need another 3rd party app for this. And I am also addicted to Ctrl+`

claunia commented

@zadjii-msft commented on GitHub (Jan 29, 2021):

Alright so pseudo-update. I've got a prototype in the works in dev/migrie/f/653-QUAKE-MODE, eff18d1ec, which is branched off #8898. It works pretty well so far! It's only got a simple setting for now, "globalHotkey": <chord>, to activate the MRU window. There's lots of other cases that people have wanted, but it does seem like good incremental progress.

I'm slowly putting the spec together in my head. Right now, it looks a bit like:

// If you specify a hotkey like this, then pressing the hotkey will summon the
// MRU Terminal window, wherever it is, no dropdown.
"globalHotkey": "<chord>",

"globalHotkey": 
{
    // The key to press to summon the Terminal
    "key": "<chord>",

    // if true, use a dropdown animation
    "dropdown": bool,

    // If true, minimize the terminal when the global hotkey is pressed and the
    // Terminal is currently active
    "hideWhenVisible": bool,

    // This is the setting I'm the least sure about. We've got lots of different
    // asks, so I want them all to be possible. This is the part that needs
    // workshopping.
    "summonMode": "mostRecentSameDesktop" | "mostRecentAnyDesktop" | "mostRecentMoveToThisDesktop" | "thisMonitor" | "thisMonitorSameDesktop"
}

It obviously needs work to make sure the relevant scenarios are adequately captured. However, I think I might just ship the "simple" version I've got in prototype now, while we work on the elaborate version.

@zadjii-msft commented on GitHub (Jan 29, 2021): Alright so pseudo-update. I've got a prototype in the works in `dev/migrie/f/653-QUAKE-MODE`, eff18d1ec, which is branched off #8898. It works pretty well so far! It's only got a simple setting for now, `"globalHotkey": <chord>`, to activate the MRU window. There's lots of other cases that people have wanted, but it does seem like good _incremental_ progress. I'm slowly putting the spec together in my head. Right now, it looks a bit like: ```jsonc // If you specify a hotkey like this, then pressing the hotkey will summon the // MRU Terminal window, wherever it is, no dropdown. "globalHotkey": "<chord>", "globalHotkey": { // The key to press to summon the Terminal "key": "<chord>", // if true, use a dropdown animation "dropdown": bool, // If true, minimize the terminal when the global hotkey is pressed and the // Terminal is currently active "hideWhenVisible": bool, // This is the setting I'm the least sure about. We've got lots of different // asks, so I want them all to be possible. This is the part that needs // workshopping. "summonMode": "mostRecentSameDesktop" | "mostRecentAnyDesktop" | "mostRecentMoveToThisDesktop" | "thisMonitor" | "thisMonitorSameDesktop" } ``` It obviously needs work to make sure the relevant scenarios are adequately captured. However, I think I might just ship the "simple" version I've got in prototype now, while we work on the elaborate version.

claunia commented

@miqm commented on GitHub (Jan 29, 2021):

// This is the setting I'm the least sure about. We've got lots of different
// asks, so I want them all to be possible. This is the part that needs
// workshopping.
"summonMode": "mostRecentSameDesktop" | "mostRecentAnyDesktop" | "mostRecentMoveToThisDesktop" | "thisMonitor" | "thisMonitorSameDesktop"

From what I noticed i.e. recently going through iTerm configuration for 'quake' mode, People tend to have it dropped to a desktop-screen where user's cursor is now.

@miqm commented on GitHub (Jan 29, 2021): > // This is the setting I'm the least sure about. We've got lots of different // asks, so I want them all to be possible. This is the part that needs // workshopping. "summonMode": "mostRecentSameDesktop" | "mostRecentAnyDesktop" | "mostRecentMoveToThisDesktop" | "thisMonitor" | "thisMonitorSameDesktop" From what I noticed i.e. recently going through iTerm configuration for 'quake' mode, People tend to have it dropped to a desktop-screen where user's cursor is now.

claunia commented

@rlabrecque commented on GitHub (Jan 30, 2021):

This is fantastic. The only thing I'd want to add is summonMode: "previousLocation or noChange or inPlace", basically I never want the physical window to move unless I move it, this should function similarly to minimizing/restoring a window. One of yours might already cover this but naming this is incredibly challenging!

@rlabrecque commented on GitHub (Jan 30, 2021): This is fantastic. The only thing I'd want to add is `summonMode: "previousLocation or noChange or inPlace"`, basically I never want the physical window to move unless I move it, this should function similarly to minimizing/restoring a window. One of yours might already cover this but naming this is incredibly challenging!

claunia commented

@j4james commented on GitHub (Jan 30, 2021):

@zadjii-msft Some time in the past I went through this thread taking notes on all the features that people were requesting, and there was one request that I think might be problematic with your current approach: the ability to have multiple hotkeys do different things (e.g. Ctrl+Alt+1 opens the terminal on monitor 1, and Ctrl+Alt+2 opens it on monitor 2).

I don't know much about the command framework, so maybe this doesn't make sense, but I had imagined it might be achieved with a command action, so you could create multiple instances of the action, each with different parameters, and bound to different key chords. Although we're talking about global hotkeys here, so maybe that's not quite the right thing.

Anyway I'm totally in favor of doing things incrementally, so I'm not suggesting we need that functionality right away, but I thought it was worth mentioning in case it affects your basic design.

    // if true, use a dropdown animation
    "dropdown": bool,

This one is minor, but I believe people also wanted to be able to control the dropdown speed, so it might be a good idea to make this an integer dropdownSpeed rather than a bool, even if it's initially just interpreted as on or off.

@j4james commented on GitHub (Jan 30, 2021): @zadjii-msft Some time in the past I went through this thread taking notes on all the features that people were requesting, and there was one request that I think might be problematic with your current approach: the ability to have multiple hotkeys do different things (e.g. <kbd>Ctrl</kbd>+<kbd>Alt</kbd>+<kbd>1</kbd> opens the terminal on monitor 1, and <kbd>Ctrl</kbd>+<kbd>Alt</kbd>+<kbd>2</kbd> opens it on monitor 2). I don't know much about the command framework, so maybe this doesn't make sense, but I had imagined it might be achieved with a command action, so you could create multiple instances of the action, each with different parameters, and bound to different key chords. Although we're talking about global hotkeys here, so maybe that's not quite the right thing. Anyway I'm totally in favor of doing things incrementally, so I'm not suggesting we need that functionality right away, but I thought it was worth mentioning in case it affects your basic design. > ```js > // if true, use a dropdown animation > "dropdown": bool, > ``` This one is minor, but I believe people also wanted to be able to control the dropdown speed, so it might be a good idea to make this an integer _dropdownSpeed_ rather than a bool, even if it's initially just interpreted as on or off.

claunia commented

@zadjii-msft commented on GitHub (Feb 1, 2021):

the ability to have multiple hotkeys do different things (e.g. Ctrl+Alt+1 opens the terminal on monitor 1, and Ctrl+Alt+2 opens it on monitor 2).

Ooof. That's a really good point. The way I had it, was just a single global-level keybinding, so having different keybindings for different desktops wouldn't have been possible. I don't want to back myself in here, so I'll need to keep that in mind.

@zadjii-msft commented on GitHub (Feb 1, 2021): > the ability to have multiple hotkeys do different things (e.g. Ctrl+Alt+1 opens the terminal on monitor 1, and Ctrl+Alt+2 opens it on monitor 2). Ooof. That's a really good point. The way I had it, was just a single global-level keybinding, so having different keybindings for different desktops wouldn't have been possible. I don't want to back myself in here, so I'll need to keep that in mind.

claunia commented

@zadjii-msft commented on GitHub (Feb 4, 2021):

Okay, I think this is everything that anyone could want from how and where to summon the window

Heck if I know what I'm gonna call those properties & enums. But not I'm thinking it's going to bey an action in the list of actions so you can have different keys do different things

// Go to the MRU window, wherever it is
{ "keys": "win+1", "command": { "action": "globalSummon", "summonTarget":"any", "destination": "origin" } },

// activate the MRU window, and move it to this desktop & this monitor
{ "keys": "win+2", "command": { "action": "globalSummon", "summonTarget":"toCurrentMonitor", "destination": "toCurrentDesktop" } },

// activate the MRU window on this desktop
{ "keys": "win+3", "command": { "action": "globalSummon", "summonTarget":"any", "destination": "sameDesktop" } },

// Activate the MRU window on monitor 2 (from any desktop), and place it on the
// current desktop. If there isn't one on monitor 2, make a new one.
{ "keys": "win+4", "command": { "action": "globalSummon", "summonTarget": 2, "destination": "toCurrentDesktop" } },

// Activate the MRU window on monitor 3 (ONLY THIS desktop), or make a new one.
{ "keys": "win+5", "command": { "action": "globalSummon", "summonTarget": 3, "destination": "sameDesktop" } },

// Activate the MRU window on this monitor (from any desktop), and place it on
// the current desktop. If there isn't one on this monitor, make a new one.
{ "keys": "win+6", "command": { "action": "globalSummon", "summonTarget": "forCurrentMonitor", "destination": "toCurrentDesktop" } },

Clearly, those property names are absurd and painful. They'll be sane by the end of a review. The other properties I mentioned earlier would also be included (including a float for dropdownSpeed). Lawdy, I hope I didn't miss some scenario.

@zadjii-msft commented on GitHub (Feb 4, 2021): Okay, I think this is everything that anyone could want from how and where to summon the window ![image](https://user-images.githubusercontent.com/18356694/106940038-a57ee480-66e6-11eb-8f61-598fb0e46ca1.png) Heck if I know what I'm gonna call those properties & enums. But not I'm thinking it's going to bey an action in the list of actions so you can have different keys do different things ```jsonc // Go to the MRU window, wherever it is { "keys": "win+1", "command": { "action": "globalSummon", "summonTarget":"any", "destination": "origin" } }, // activate the MRU window, and move it to this desktop & this monitor { "keys": "win+2", "command": { "action": "globalSummon", "summonTarget":"toCurrentMonitor", "destination": "toCurrentDesktop" } }, // activate the MRU window on this desktop { "keys": "win+3", "command": { "action": "globalSummon", "summonTarget":"any", "destination": "sameDesktop" } }, // Activate the MRU window on monitor 2 (from any desktop), and place it on the // current desktop. If there isn't one on monitor 2, make a new one. { "keys": "win+4", "command": { "action": "globalSummon", "summonTarget": 2, "destination": "toCurrentDesktop" } }, // Activate the MRU window on monitor 3 (ONLY THIS desktop), or make a new one. { "keys": "win+5", "command": { "action": "globalSummon", "summonTarget": 3, "destination": "sameDesktop" } }, // Activate the MRU window on this monitor (from any desktop), and place it on // the current desktop. If there isn't one on this monitor, make a new one. { "keys": "win+6", "command": { "action": "globalSummon", "summonTarget": "forCurrentMonitor", "destination": "toCurrentDesktop" } }, ``` Clearly, those property names are absurd and painful. They'll be sane by the end of a review. The other properties I mentioned earlier would also be included (including a `float` for `dropdownSpeed`). Lawdy, I hope I didn't miss some scenario.

claunia commented

@zakius commented on GitHub (Feb 5, 2021):

am I missing something or you haven't started working on the hiding action yet? and extending that on toggle?

@zakius commented on GitHub (Feb 5, 2021): am I missing something or you haven't started working on the hiding action yet? and extending that on toggle?

claunia commented

@zadjii-msft commented on GitHub (Feb 5, 2021):

@zakius I'm sorry could you clarify? My current plan is to use the "hideWhenVisible": bool property in the action to let the user pick:

when true: if the Terminal Window is currently active when the keybinding is pressed, then minimize the window. Otherwise, try to summon a window
when false: if the Terminal Window is currently active when the keybinding is pressed, nothing happens

I'm then planning a whole other setting for "minimize to tray" (thus hiding it from the taskbar). That prototyping I haven't done so much of yet, but I think will be easier?

Is that what you're looking for?

@zadjii-msft commented on GitHub (Feb 5, 2021): @zakius I'm sorry could you clarify? My current plan is to use the `"hideWhenVisible": bool` property in the action to let the user pick: * when `true`: if the Terminal Window is currently active when the keybinding is pressed, then minimize the window. Otherwise, try to summon a window * when `false`: if the Terminal Window is currently active when the keybinding is pressed, nothing happens I'm then planning a whole other setting for "minimize to tray" (thus hiding it from the taskbar). That prototyping I haven't done so much of yet, but I _think_ will be easier? Is that what you're looking for?

claunia commented

@zakius commented on GitHub (Feb 5, 2021):

okay, I understand now, the code already is quite complex but I couldn't see anything related to hiding from taskbar so I wasn't sure if I missed it or you still have to get there

@zakius commented on GitHub (Feb 5, 2021): okay, I understand now, the code already is quite complex but I couldn't see anything related to hiding from taskbar so I wasn't sure if I missed it or you still have to get there

claunia commented

@rlabrecque commented on GitHub (Feb 5, 2021):

Minimize to tray is definitely a completely separate feature IMO.

You could have it minimize to tray whether or not you're using globalSummon 👍

@rlabrecque commented on GitHub (Feb 5, 2021): Minimize to tray is definitely a completely separate feature IMO. You could have it minimize to tray whether or not you're using globalSummon 👍

claunia commented

@dnet890 commented on GitHub (Mar 22, 2021):

I can see now that microsoft terminal will be shipped as a default app on the future version of Windows. Is there any specific date for this feature to be implemented?

@dnet890 commented on GitHub (Mar 22, 2021): I can see now that microsoft terminal will be shipped as a default app on the future version of Windows. Is there any specific date for this feature to be implemented?

claunia commented

2026-01-30 22:11:38 +00:00

@zadjii-msft commented on GitHub (Mar 22, 2021):

Nope. If there was, it would be in a more specific milestone then just the broad 2.0.

@zadjii-msft commented on GitHub (Mar 22, 2021): Nope. If there was, it would be in a more specific milestone then just the broad 2.0.

claunia commented

@cyberhck commented on GitHub (Mar 23, 2021):

another question, so bring the window on the monitor where the cursor currently is, is that covered? is that handled by MRU?

@cyberhck commented on GitHub (Mar 23, 2021): another question, so bring the window on the monitor where the cursor currently is, is that covered? is that handled by MRU?

claunia commented

2026-01-30 22:11:38 +00:00

@zadjii-msft commented on GitHub (Mar 23, 2021):

@cyberhck yep, that's covered. I'd go check out #9274 for more details:

{ "keys": "win+6", "command":{ "action":"globalSummon", "monitor": "toCurrent" } },

That'll summon the window to the current monitor.

@zadjii-msft commented on GitHub (Mar 23, 2021): @cyberhck yep, that's covered. I'd go check out #9274 for more details: ```jsonc { "keys": "win+6", "command":{ "action":"globalSummon", "monitor": "toCurrent" } }, ``` That'll summon the window to the current monitor.

claunia commented

2026-01-30 22:11:38 +00:00

@dnet890 commented on GitHub (Mar 23, 2021):

because microsoft terminal is younger than conemu. I hope Microsoft terminal is more stable and reliable than conemu

@dnet890 commented on GitHub (Mar 23, 2021): because microsoft terminal is younger than conemu. I hope Microsoft terminal is more stable and reliable than conemu

claunia commented

2026-01-30 22:11:39 +00:00

@mkanet commented on GitHub (Apr 29, 2021):

Does anyone know which version of MS Terminal will include the hotkey dropdown ala quake feature? I've been using Windows-Terminal-Quake companion app. Honestly, I wouldn't use Terminal without this companion app ...at least, until there's native support for this capability.

@mkanet commented on GitHub (Apr 29, 2021): Does anyone know which version of MS Terminal will include the **_hotkey dropdown ala quake_** feature? I've been using [Windows-Terminal-Quake companion](https://github.com/flyingpie/windows-terminal-quake) app. Honestly, I wouldn't use Terminal without this companion app ...at least, until there's native support for this capability.

claunia commented

2026-01-30 22:11:39 +00:00

@DHowett commented on GitHub (Apr 29, 2021):

Believe me, you will receive a notification when a version of Terminal is released with this change if only you'd click the Subscribe button.

@DHowett commented on GitHub (Apr 29, 2021): Believe me, you will receive a notification when a version of Terminal is released with this change _if only you'd click the Subscribe button._

claunia commented

2026-01-30 22:11:39 +00:00

@kellware commented on GitHub (Apr 29, 2021):

Is this the place to propose additional features for quake mode?

I would like a secondary key which is used solely to hide quake window if it is active/in focus. I see in the mega thread that the quakeMode action is used to summon and hide the window. But I would like to optionally use another key to hide the window. In my case it would be the escape key.

@kellware commented on GitHub (Apr 29, 2021): Is this the place to propose additional features for quake mode? I would like a secondary key which is used solely to hide quake window if it is active/in focus. I see in the mega thread that the quakeMode action is used to summon and hide the window. But I would like to optionally use another key to hide the window. In my case it would be the escape key.

claunia commented

@Defcon0 commented on GitHub (Apr 29, 2021):

What would also be important is to hide the window‘s title bar. At least this is what tilda/guake are doing which is cool because this way more space is available for content.

@Defcon0 commented on GitHub (Apr 29, 2021): What would also be important is to hide the window‘s title bar. At least this is what tilda/guake are doing which is cool because this way more space is available for content.

claunia commented

@kellware commented on GitHub (Apr 29, 2021):

@Defcon0 according to this checklist, quake mode will open in focus mode which hides tabs and titlebar. Read about focus mode here: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-2-release/#focus-mode

You can add a keybinding for toggleFocusMode to see what it looks like yourself.

@kellware commented on GitHub (Apr 29, 2021): @Defcon0 according to [this](https://github.com/microsoft/terminal/issues/8888) checklist, quake mode will open in focus mode which hides tabs and titlebar. Read about focus mode here: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-2-release/#focus-mode You can add a keybinding for toggleFocusMode to see what it looks like yourself.

claunia commented

@zadjii-msft commented on GitHub (Apr 29, 2021):

I mean, technically the place to suggest features would have been in #9274 - but we can continue the discussion here.

Using esc to dismiss the window might be fraught with peril - that's a key that's used by plenty of other commandline applications, as well as apps in general. So I definitely wouldn't want to globally bind that one. I guess hypothetically we could add a dismissWindow action, that you could bind to esc to minimize/hide the window.

hide the window‘s title bar. At least this is what tilda/guake are doing which is cool because this way more space is available for content.

You'll be happy to know that the _quake window will already open in focus mode by default, see #9785

@zadjii-msft commented on GitHub (Apr 29, 2021): I mean, technically the place to suggest features would have been in #9274 - but we can continue the discussion here. Using <kbd>esc</kbd> to dismiss the window might be fraught with peril - that's a key that's used by plenty of other commandline applications, as well as apps in general. So I definitely wouldn't want to globally bind that one. I guess hypothetically we could add a `dismissWindow` action, that you could bind to <kbd>esc</kbd> to minimize/hide the window. <hr> > hide the window‘s title bar. At least this is what tilda/guake are doing which is cool because this way more space is available for content. You'll be happy to know that the `_quake` window will already open in focus mode by default, see #9785

claunia commented

@kellware commented on GitHub (Apr 29, 2021):

@zadjii-msft I didn't think about that. I think I could get along with just using the summon action then.

@kellware commented on GitHub (Apr 29, 2021): @zadjii-msft I didn't think about that. I think I could get along with just using the summon action then.

claunia commented

@rlabrecque commented on GitHub (Apr 29, 2021):

Just a note, it's important to think about features as part of the bigger picture, @zadjii-msft mentioned the dismissWindow action which could be an entirely separate feature by itself, completely unrelated to quake mode. 👍

@rlabrecque commented on GitHub (Apr 29, 2021): Just a note, it's important to think about features as part of the bigger picture, @zadjii-msft mentioned the `dismissWindow` action which could be an entirely separate feature by itself, completely unrelated to quake mode. 👍

claunia commented

@ghost commented on GitHub (May 25, 2021):

:tada:This issue was addressed in #9854, which has now been successfully released as Windows Terminal Preview v1.9.1445.0.🎉

Handy links:

@ghost commented on GitHub (May 25, 2021): :tada:This issue was addressed in #9854, which has now been successfully released as `Windows Terminal Preview v1.9.1445.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.9.1445.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)

claunia commented

@mkanet commented on GitHub (May 25, 2021):

🎉This issue was addressed in #9854, which has now been successfully released as Windows Terminal Preview v1.9.1445.0.🎉

Handy links:

Release Notes

Store Download

Could someone please post example settings I can add in my settings.json file to enable Quakemode toggle via Control+Shift+C hotkey combo? Also, how do I change the Quakemode window to only drop-down on the right side of my desktop ...similar to how I would do it in Windows-Terminal-Quake companion? Thanks in advance for all the hard work getting this working.

@mkanet commented on GitHub (May 25, 2021): > 🎉This issue was addressed in #9854, which has now been successfully released as `Windows Terminal Preview v1.9.1445.0`.🎉 > > Handy links: > > * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.9.1445.0) > * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge) Could someone please post example settings I can add in my `settings.json` file to enable Quakemode toggle via `Control+Shift+C` hotkey combo? Also, how do I change the Quakemode window to only drop-down on the right side of my desktop ...similar to how I would do it in [Windows-Terminal-Quake companion](https://github.com/flyingpie/windows-terminal-quake)? Thanks in advance for all the hard work getting this working.

claunia commented

@strinnityk commented on GitHub (May 26, 2021):

🎉This issue was addressed in #9854, which has now been successfully released as Windows Terminal Preview v1.9.1445.0.🎉
Handy links:

Release Notes

Store Download

Could someone please post example settings I can add in my settings.json file to enable Quakemode toggle via Control+Shift+C hotkey combo? Also, how do I change the Quakemode window to only drop-down on the right side of my desktop ...similar to how I would do it in Windows-Terminal-Quake companion? Thanks in advance for all the hard work getting this working.

Link to the official docs where it's easily explained.

This is the setting you are looking for:

{ "keys": "win+`", "command": { "action": "quakeMode" } }

You need to go to Settings>Open JSON file and add that setting under the actions array like so:

{
    "actions": [
        ...,
        {
            "command": { "action": "quakeMode" },
            "keys": "ctrl+f12"  // I changed mine to this, feel free to set the keybinding of your preference
        },
    ],
    ...
}

P.S: Remember this only works in the preview build that you can download from the store.

@strinnityk commented on GitHub (May 26, 2021): > > > > 🎉This issue was addressed in #9854, which has now been successfully released as `Windows Terminal Preview v1.9.1445.0`.🎉 > > Handy links: > > > > * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.9.1445.0) > > * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge) > > Could someone please post example settings I can add in my `settings.json` file to enable Quakemode toggle via `Control+Shift+C` hotkey combo? Also, how do I change the Quakemode window to only drop-down on the right side of my desktop ...similar to how I would do it in [Windows-Terminal-Quake companion](https://github.com/flyingpie/windows-terminal-quake)? Thanks in advance for all the hard work getting this working. [Link](https://docs.microsoft.com/en-gb/windows/terminal/customize-settings/actions#open-the-quake-mode-window-preview) to the official docs where it's easily explained. This is the setting you are looking for: ``` { "keys": "win+`", "command": { "action": "quakeMode" } } ``` You need to go to Settings>Open JSON file and add that setting under the `actions` array like so: ``` { "actions": [ ..., { "command": { "action": "quakeMode" }, "keys": "ctrl+f12" // I changed mine to this, feel free to set the keybinding of your preference }, ], ... } ``` P.S: Remember this only works in the preview build that you can download from the store.

claunia commented

@wandoschneider commented on GitHub (May 26, 2021):

🎉This issue was addressed in #9854, which has now been successfully released as Windows Terminal Preview v1.9.1445.0.🎉
Handy links:

Release Notes

Store Download

Could someone please post example settings I can add in my settings.json file to enable Quakemode toggle via Control+Shift+C hotkey combo? Also, how do I change the Quakemode window to only drop-down on the right side of my desktop ...similar to how I would do it in Windows-Terminal-Quake companion? Thanks in advance for all the hard work getting this working.

Link to the official docs where it's easily explained.

This is the setting you are looking for:
{ "keys": "win+`", "command": { "action": "quakeMode" } }
You need to go to Settings>Open JSON file and add that setting under the actions array like so:
{
    "actions": [
        ...,
        {
            "command": { "action": "quakeMode" },
            "keys": "ctrl+f12"  // I changed mine to this, feel free to set the keybinding of your preference
        },
    ],
    ...
}
P.S: Remember this only works in the preview build that you can download from the store.

Works great, but only after I manually open WT. After I boot Windows, does nothing.

@wandoschneider commented on GitHub (May 26, 2021): > > > > > 🎉This issue was addressed in #9854, which has now been successfully released as `Windows Terminal Preview v1.9.1445.0`.🎉 > > > Handy links: > > > > > > * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.9.1445.0) > > > * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge) > > > > > > Could someone please post example settings I can add in my `settings.json` file to enable Quakemode toggle via `Control+Shift+C` hotkey combo? Also, how do I change the Quakemode window to only drop-down on the right side of my desktop ...similar to how I would do it in [Windows-Terminal-Quake companion](https://github.com/flyingpie/windows-terminal-quake)? Thanks in advance for all the hard work getting this working. > > [Link](https://docs.microsoft.com/en-gb/windows/terminal/customize-settings/actions#open-the-quake-mode-window-preview) to the official docs where it's easily explained. > > This is the setting you are looking for: > > ``` > { "keys": "win+`", "command": { "action": "quakeMode" } } > ``` > > You need to go to Settings>Open JSON file and add that setting under the `actions` array like so: > > ``` > { > "actions": [ > ..., > { > "command": { "action": "quakeMode" }, > "keys": "ctrl+f12" // I changed mine to this, feel free to set the keybinding of your preference > }, > ], > ... > } > ``` > > P.S: Remember this only works in the preview build that you can download from the store. Works great, but only after I manually open WT. After I boot Windows, does nothing.

claunia commented

@strinnityk commented on GitHub (May 26, 2021):

@wandoschneider I would say that, for guake mode to work, the terminal has to running, so it can listen for commands. You can easily solve that changing this:
Settings>Startup>"Launch on machine startup" set to "On"

I don't know, though, if there's a way to launch it minimized to taskbar. Maybe it already does, I haven't tested out that feature yet.

@strinnityk commented on GitHub (May 26, 2021): @wandoschneider I would say that, for guake mode to work, the terminal has to running, so it can listen for commands. You can easily solve that changing this: ```Settings>Startup>"Launch on machine startup" set to "On"``` I don't know, though, if there's a way to launch it minimized to taskbar. Maybe it already does, I haven't tested out that feature yet.

claunia commented

@zakius commented on GitHub (May 26, 2021):

is there a way to hide the window, not just minimize it?

@zakius commented on GitHub (May 26, 2021): is there a way to hide the window, not just minimize it?

claunia commented

@wandoschneider commented on GitHub (May 26, 2021):

@wandoschneider I would say that, for guake mode to work, the terminal has to running, so it can listen for commands. You can easily solve that changing this:
Settings>Startup>"Launch on machine startup" set to "On"

I don't know, though, if there's a way to launch it minimized to taskbar. Maybe it already does, I haven't tested out that feature yet.

I have figured that out. But opening the windows every time I boot the OS is unnecessary.

@wandoschneider commented on GitHub (May 26, 2021): > > > @wandoschneider I would say that, for guake mode to work, the terminal has to running, so it can listen for commands. You can easily solve that changing this: > `Settings>Startup>"Launch on machine startup" set to "On"` > > I don't know, though, if there's a way to launch it minimized to taskbar. Maybe it already does, I haven't tested out that feature yet. I have figured that out. But opening the windows every time I boot the OS is unnecessary.

claunia commented

2026-01-30 22:11:43 +00:00

@runofthemillgeek commented on GitHub (May 26, 2021):

is there a way to hide the window, not just minimize it?

I believe this is still being worked upon. See #5727 for the issue and #10179 for some of the work.

Also follow the megathread at #8888

@runofthemillgeek commented on GitHub (May 26, 2021): > is there a way to hide the window, not just minimize it? I believe this is still being worked upon. See #5727 for the issue and #10179 for some of the work. Also follow the megathread at #8888

claunia commented

@mkanet commented on GitHub (May 26, 2021):

I have a couple of more questions. I wasn't sure where else to ask...

Is there a way to configure Terminal Preview Quake mode to only open on the right side of the screen? Currently, quake mode takes up the entire width of my widescreen monitor. I couldn't find how to specify the quake window size and how to dock it to the right side of my desktop.

Also, is there a way to change Quake Mode the animation speed?

@mkanet commented on GitHub (May 26, 2021): I have a couple of more questions. I wasn't sure where else to ask... Is there a way to configure Terminal Preview Quake mode to only open on the right side of the screen? Currently, quake mode takes up the entire width of my widescreen monitor. I couldn't find how to specify the quake window size and how to dock it to the right side of my desktop. Also, is there a way to change Quake Mode the animation speed?

claunia commented

2026-01-30 22:11:43 +00:00

@tristanjthompson commented on GitHub (May 26, 2021):

@mkanet

I have a couple of more questions. I wasn't sure where else to ask...

Is there a way to configure Terminal Preview Quake mode to only open on the right side of the screen? Currently, quake mode takes up the entire width of my widescreen monitor. I couldn't find how to specify the quake window size and how to dock it to the right side of my desktop.

Also, is there a way to change Quake Mode the animation speed?

The new feature is actually globalSummon - "Quake" mode is a pre-configuration of that new feature. They've got documentation for it here

Here's my configuration for it (it goes in the actions section of the settings.json) if that's helpful to go by:

     {    
      "command": {
        "action": "globalSummon",
        "dropdownDuration":  200,
        "monitor": "any" // keeps it on the same monitor
      },
      "keys": "ctrl+'"
    },

This will summon it to the same monitor/place it was originally on (I prefer it to always be on my middle monitor), have an animation speed of 200ms and is summoned with ctrl+'.

I don't think you can specify the position that it's summoned to, but you can set it to only summon the existing terminal. I've found the settings that let you specify, during startup, the initial position, rows & columns (the rows & columns are exposed in the settings gui, but the initial position isn't). You can probably get it to startup in a position on the right-hand side of the screen at a certain size (i.e. the position you'd like it in) and then never move it. Those settings are added to the root (you've probably already got the initialCols and initialRows in there):

  "initialCols": 215,
  "initialPosition": "60,0",
  "initialRows": 45,

I've set mine up to start at the top of the screen, slightly in, and then have it wide enough to take up about 90% of the width of my screen (which is what I prefer)

@tristanjthompson commented on GitHub (May 26, 2021): @mkanet > > > I have a couple of more questions. I wasn't sure where else to ask... > > Is there a way to configure Terminal Preview Quake mode to only open on the right side of the screen? Currently, quake mode takes up the entire width of my widescreen monitor. I couldn't find how to specify the quake window size and how to dock it to the right side of my desktop. > > Also, is there a way to change Quake Mode the animation speed? The new feature is actually `globalSummon` - "Quake" mode is a pre-configuration of that new feature. They've got documentation for it [here](https://docs.microsoft.com/en-gb/windows/terminal/customize-settings/actions#global-summon-preview) Here's my configuration for it (it goes in the `actions` section of the settings.json) if that's helpful to go by: ``` { "command": { "action": "globalSummon", "dropdownDuration": 200, "monitor": "any" // keeps it on the same monitor }, "keys": "ctrl+'" }, ``` This will summon it to the same monitor/place it was originally on (I prefer it to always be on my middle monitor), have an animation speed of 200ms and is summoned with `ctrl+'`. I don't think you can specify the position that it's summoned to, but you can set it to only summon the existing terminal. I've found the settings that let you specify, during startup, the initial position, rows & columns (the rows & columns are exposed in the settings gui, but the initial position isn't). You can probably get it to startup in a position on the right-hand side of the screen at a certain size (i.e. the position you'd like it in) and then never move it. Those settings are added to the root (you've probably already got the `initialCols` and `initialRows` in there): ``` "initialCols": 215, "initialPosition": "60,0", "initialRows": 45, ``` I've set mine up to start at the top of the screen, slightly in, and then have it wide enough to take up about 90% of the width of my screen (which is what I prefer)

claunia commented

2026-01-30 22:11:43 +00:00

@mkanet commented on GitHub (May 26, 2021):

@tristanjthompson thank you. When I use "action": "globalSummon", instead of the terminal dropping down from the top of my screen (what I expect), the window just minimizes to the taskbar and back.

If I use "action": "quakeMode" It does drop down from the top of my monitor.. .however, it ignores all the settings I have to control the initial size and position: I.E., initialPosition, initialCols, etc.

Is there a way to use Quakemode with the flexibility to control size and position? All I'm trying to do is reproduce Quakemode I would expect when using apps like ConEmu or Windows-Terminal-Quake companion.

@mkanet commented on GitHub (May 26, 2021): @tristanjthompson thank you. When I use `"action": "globalSummon"`, instead of the terminal dropping down from the top of my screen (what I expect), the window just minimizes to the taskbar and back. If I use `"action": "quakeMode"` It _does_ drop down from the top of my monitor.. .however, it ignores all the settings I have to control the initial size and position: I.E., `initialPosition`, `initialCols`, etc. Is there a way to use Quakemode with the flexibility to control size and position? All I'm trying to do is reproduce Quakemode I would expect when using apps like [ConEmu](https://conemu.github.io/) or [Windows-Terminal-Quake companion](https://github.com/flyingpie/windows-terminal-quake).

claunia commented

@tristanjthompson commented on GitHub (May 27, 2021):

@tristanjthompson thank you. When I use "action": "globalSummon", instead of the terminal dropping down from the top of my screen (what I expect), the window just minimizes to the taskbar and back.

@mkanet If you set a dropdownDuration it will drop down from the top - as globalSummon respects the initial position/size settings then with this in place it should do everything you've mentioned. All of its capabilities are in the documentation - check it out and have play!

@tristanjthompson commented on GitHub (May 27, 2021): > @tristanjthompson thank you. When I use `"action": "globalSummon"`, instead of the terminal dropping down from the top of my screen (what I expect), the window just minimizes to the taskbar and back. @mkanet If you set a `dropdownDuration` it will drop down from the top - as `globalSummon` respects the initial position/size settings then with this in place it should do everything you've mentioned. All of its capabilities are in the [documentation](https://docs.microsoft.com/en-gb/windows/terminal/customize-settings/actions#global-summon-preview) - check it out and have play!

claunia commented

@sharunkumar commented on GitHub (May 27, 2021):

Great that this feature got released. Now gotta wait for system tray support and startup to system tray 👍

@sharunkumar commented on GitHub (May 27, 2021): Great that this feature got released. Now gotta wait for system tray support and startup to system tray 👍

claunia commented

@jelster commented on GitHub (May 27, 2021):

@zadjii-msft and @DHowett-MSFT and the whole Terminal team -- great job getting this shipped! It's been a long journey, and I'm really amazed at what you've all achieved!

👍 🚀 🥇

@jelster commented on GitHub (May 27, 2021): @zadjii-msft and @DHowett-MSFT and the whole Terminal team -- great job getting this shipped! It's been a long journey, and I'm really amazed at what you've all achieved! 👍 🚀 🥇

claunia commented

@zadjii-msft commented on GitHub (May 27, 2021):

READ ME

Since there's been a ton of questions on the topic in the last two days, I've added a Quake mode FAQ. If it's not covered there, then feel free to ask follow-ups in #8888. That's the thread that we'll be using for additional follow ups on quakeMode and globalSummon

GO HERE -> #8888

@zadjii-msft commented on GitHub (May 27, 2021): # READ ME Since there's been a ton of questions on the topic in the last two days, I've added a [Quake mode FAQ](https://github.com/microsoft/terminal/wiki/Frequently-Asked-Questions-(FAQ)#quake-mode--global-summon). If it's not covered there, then feel free to ask follow-ups in #8888. That's the thread that we'll be using for additional follow ups on `quakeMode` and `globalSummon` # GO HERE -> #8888

claunia commented

@dailytabs commented on GitHub (Jun 2, 2021):

Applications should have been opening on the screen they were triggered on for 20 years. Having to fix this on a per app level is atrocious behavior from the OS. Having to waste time on this, instead of actual features, is appalling. Great, I can get my window on my display of choice, but it's still terribly wide and can't be configured. But, sure, let's fix a long-running Windows issue inside our app, instead.

Seriously, WTF hasn't MS fixed this: Google "windows open application on specific monitor" > About 826,000,000 results

@dailytabs commented on GitHub (Jun 2, 2021): Applications should have been opening on the screen they were triggered on for 20 years. Having to fix this on a per app level is atrocious behavior from the OS. Having to waste time on this, instead of actual features, is appalling. Great, I can get my window on my display of choice, but it's still terribly wide and can't be configured. But, sure, let's fix a long-running Windows issue inside our app, instead. Seriously, WTF hasn't MS fixed this: Google "windows open application on specific monitor" > About 826,000,000 results

claunia commented

@DHowett commented on GitHub (Jun 2, 2021):

Great, I can get my window on my display of choice, but it's still terribly wide and can't be configured.

We're trying to celebrate progress even though it's short of perfection. This is an area of active investment. 😄

@DHowett commented on GitHub (Jun 2, 2021): > Great, I can get my window on my display of choice, but it's still terribly wide and can't be configured. We're trying to celebrate progress even though it's short of perfection. This is an area of active investment. :smile:

claunia commented

@cyberhck commented on GitHub (Jun 3, 2021):

wow,
This is an open source project, and it's just started, please be patience and don't use aggressive language. Please read the code of conduct and behave in a calm and professional manner.

What we can celebrate for is instead of microsoft not caring what customer wants, now they're developing few things in the open, we at least had the say in what feature is requested. For some people which includes me, even though I have 3 monitors, having a popup terminal is a must, if you're using something not actually released bundled with OS and installing from a store which is might still be in beta stage, instead of using offensive language like that, how about creating a new issue, thanking everyone who made this feature possible and asking to configure width and height, where it pops from etc for next release?

Wouldn't that be more productive than: "Seriously, WTF hasn't MS fixed this: Google "windows open application on specific monitor"" > About 826,000,000 results"?

Seriously?

@cyberhck commented on GitHub (Jun 3, 2021): wow, This is an open source project, and it's just started, please be patience and don't use aggressive language. Please read the code of conduct and behave in a calm and professional manner. What we can celebrate for is instead of microsoft not caring what customer wants, now they're developing few things in the open, we at least had the say in what feature is requested. For some people which includes me, even though I have 3 monitors, having a popup terminal is a must, if you're using something not actually released bundled with OS and installing from a store which is might still be in beta stage, instead of using offensive language like that, how about creating a new issue, thanking everyone who made this feature possible and asking to configure width and height, where it pops from etc for next release? Wouldn't that be more productive than: "Seriously, WTF hasn't MS fixed this: Google "windows open application on specific monitor"" > About 826,000,000 results"? Seriously?

claunia commented

@orcmid commented on GitHub (Jun 3, 2021):

From @cyberhck

This is an open source project
...,
What we can celebrate [is Mkcrosoft] developing few things in the open.

Yes, I think this is a great move on the part of those Microsoft projects that are able to do so. It is not the same as an open-source project with transparent governance. It is extremely valuable. and to be celebrated.

Most of all, I want the Microsoft contributors and governors of this project to find it worthwhile and satisfying while serving the interests of their employer and, best of all, shipping code.

I think this s a learning experience for all involved and it is important to be patient, tolerant, and kind.

@orcmid commented on GitHub (Jun 3, 2021): From @cyberhck > This is an open source project ..., > What we can celebrate [is Mkcrosoft] developing few things in the open. Yes, I think this is a great move on the part of those Microsoft projects that are able to do so. It is not the same as an open-source project with transparent governance. It is extremely valuable. and to be celebrated. Most of all, I want the Microsoft contributors and governors of this project to find it worthwhile and satisfying while serving the interests of their employer and, best of all, shipping code. I think this s a learning experience for all involved and it is important to be patient, tolerant, and kind.

claunia commented