The petty thing I miss most when I pop into Windows is having a separate hot key terminal for each of my three monitors. The closest i've ever been to believing in god was when I realized that was obtainable and if you could make that happen in Windows I just might have to kiss you.
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?
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.
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.
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 are you sure it should be where the mouse is, and not where the currently focused window is?
@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).
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.
+1
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:
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.
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
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+\
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
I would consider developing on windows more (currently 95% done on Linux) if I had a terminal that could drop down like guake.
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.
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
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 you have most of what people are asking for right, but @cyberhck and @zakius identified a couple other features that might be important:
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.)
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
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.
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
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.
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.
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 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.
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):
All of those are roughly blockers for me switching to wt.exe from ConEmu.
Additionally:
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?
So you've listed a number of separate issues, lemme see if I can link them all:
Out of those, #1043, #653, #2189 are all marked "Help-Wanted" 😉
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)
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.
@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.
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
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.
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).
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 reasonableI 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
.
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.
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.
@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.
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.
Is that not what comment https://github.com/microsoft/terminal/issues/653#issuecomment-520419611 is describing?
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.
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)
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).
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
}
}
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:
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
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.
I went ahead and started a project, pretty much because of this feature. https://github.com/dotjosh/WinTermPlus
@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?
@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.
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:
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.
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.)
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.
May I suggest starting with the user experience of other popular terminals and altering it from there if they are suboptimal?
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.
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.
See above - both. It toggles their states.
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.
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
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"
}
}
]
A Quake console style hotkey (ConEmu) is a must. Has anyone been able to attached Terminal to ConEmu?
@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?
I wanna say love what you're doing with the new Terminal. And I totally understand not being able to get to a feature request due to other prioritized tickets. This happens to every team, my team is not immune to this either.
But I have to say the lack of this feature is the failing of the PM and kinda shows they don't fully understand the impact of this feature on so many users. This is what, a 2 pointer? maybe 3?
This is a low hanging fruit feature that has a huge amount of impact. I like that you guys accept public PRs, but if the public isn't doing it, pull this into a sprint. This ticket has been open for a year.
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)
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?
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.
I'm not saying those features aren't important at all. My point is, this is a low hanging fruit with almost 300 thumbs up, multiple duplicate tickets created about it and isn't as involved as most of the other features / bug fixes you have listed.
I don't mean to belittle the work being done here, on the contrary I think what the team has accomplished is amazing. Both the team and you deserve credit.
Maybe I was a bit harsh, so I apologize for that. But I still think my point stands. It's up to you and the team to decide of course, just my two cents.
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.
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?
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
Adding my two cents to the discussion, my modified version of the AutoHotKey
script provided by @kimbirkelund:
Ctrl + ~
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()
}
}
@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 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"
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.
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.
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.
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
_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.
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 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.
@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 When I tell people about the magic elevator modifier, they always say "whattttt"
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.[email protected]. 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.
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.
This feature is very time saving.
Really looking forward to Windows Terminal 2.0
Very much watned feature, would really make the environment switch betwenn Linux and Windows a lot nicer.
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
The team released a roadmap and this issue is in there 🥳 Although it has priority 3 in a scale from 0 to 2 😢
Sorry, our scale actually does go to 3. Whoops! :smile:
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.
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.
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.
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
Not neccessarily. It just means that Microsoft staff won't work on it.
Anyone can submit the feature as a PR.
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
@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
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
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.
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).
no, it's not the same thing
minimize != hide window
window hiding makes it get out of your way completely
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.
This is the most upvoted feature request and has been open for over a year??
How the hell is this not implemented yet?
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.
SendMessage(WM_SETHOTKEY)
method above.)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.
https://github.com/microsoft/PowerToys/blob/49b56d9b52bdfedd6ad1404bd0b20e884d2b574b/src/modules/shortcut_guide/shortcut_guide.cpp#L150-L173
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
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.
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" :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 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
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.
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 + `
*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
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..
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.
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 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!
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+`
Most helpful comment
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.