Change:
const workbenchRegistry = Registry.as<IWorkbenchContributionsRegistry>(WorkbenchExtensions.Workbench); workbenchRegistry.registerWorkbenchContribution(EditorAccessibilityHelpContribution, LifecyclePhase.Eventually); <ins> workbenchRegistry.registerWorkbenchContribution(UnfocusedViewDimmingContribution, LifecyclePhase.Restored); </ins>

Discussion:
One of the best features of VS Code is the built-in terminal. However, I often begin typing in the editor when in fact I think I'm in the terminal - and vice versa. To alleviate this issue, it would be helpful to visually indicate which portion of the IDE is "active" vs. "inactive". A subtle dimming effect might just do the trick.
Of course, this would be best suited as an option and, since it could be jarring to current users, not the default behavior. Personally, I could also see this being useful in split-editor views as well.
Some things that could help you with this: , this is how I tell where the focus is. The terminal cursor is also hollow when it's not focused which helps. The high contrast theme adds a border around the terminal when it's focused: ! Probably not much of a workaround but worth mentioning :wink: what are your thoughts on maybe having an option something like which would draw the focus border around whatever is focused. Right not a border is not drawn when focusing the editor and panels. This could be useful to give an extra visual cue on which part of the workbench is focused. It would also be particularly nice when working with the commands. We used to show the border around the explorer not that long ago which i actually liked. A border around the terminal and editor would be nice too. Alternatively an option to dim the non-active view as proposed by the OP.
thanks for the response! I do have blinking cursor set currently and when I'm on my macbook it's usually in a close enough proximity (visually) so that I see it but when I'm on my two large external displays at fullscreen it's easy to miss the blinking cursor if you're looking elsewhere and working quickly. The high contrast mode makes my eyes bleed haha. None the less, that's great to point out here. +1 on the focus border you have suggested. Thanks again
I do not like the border (in fact I even get annoyed by our blue focus ring so I disabled it via theme customization). I would prefer a solution that does not introduce ugly borders.
What are you thoughts on the dimming effect? Possibly with an optional "amount"?

iTerm is an example of this: <img width="1440" alt="screen shot 2017-07-12 at 1 14 52 pm" src="https://user-"
I prefer borders personally :stuckouttongue: !
Yeah dimming might be better. We have this problem already today where when having multiple editors open side by side it is not clear which editor is active.
is anyone currently working on this request? I'm interested in implementing it.
I'm not sure there is clear way forward right now.
I experience a similar issue as well, specifically when switching between windows. I'll have my web browser "active" and then click on the terminal area of my VS Code window expecting the cursor to be in the terminal so I can start typing commands, however the cursor is unexpectedly placed in the editor. I have to click the terminal area a second time. It'd be great if clicking on the terminal area of an inactive VS Code window would make it active with the cursor in the terminal rather than the editor. Is that a reasonable fix? or should I open a separate issue for this suggestion
+1 for dimming the inactive editor/terminal windows. I always edit in split window mode, and I would really like the inactive windows to be dimmed. I have been using this plugin for sublime text 3 for 3 years now, and it has convinced me that subtle, full pane dimming, is the most effective way to emphasise or de-emphasise an editor pane.
I also usually edit with a split editor and one or more split terminals, using homerow keybindings to navigate around them. While my color theme (spacemacs dark)'s dimmed tab colors, a hard-blinking block cursor, and the active line indicator does give me some indication of which split is active, I'm still often mistakenly typing into the wrong pane because these subtle cues take a lot of attention to notice. I really like iTerm2's adjustable inactive pane dimming, it's implemented very well in my opinion. When I have some time I'd like to see if this effect can be hacked in the color theme. Anyone try this yet?
I was bugged by this too, while I wasn't able to make take care of terminal pane did a naive impl for text document at least: until this feature lands in editor.

This frustrates me at least a few times a day. Dimming by a configurable amount seems like the clear winner. We should have this by now. Do we vote on it somewhere?
Throwing in my vote here... +1 Mainly the terminal window. I can't count the times anymore I've mistakenly typed and overwritten stuff in the editor window, instead of the terminal window.
Someone needs to re-open this issue as a feature request so that it gets the whole voting thing. or maybe one of the VSCode staff can update this issue. ?
it's in the backlog and unlocked so it can be voted on just fine currently?
Sorry - not sure I understand the question. If you're asking if my original comment is descriptive enough to be voted on then yes, I think it is accurate enough. I'd be happy to revise or provide more detail if needed.
Specifically, folks should take note of the first two comments in this issue and the image/example of iTerm2 shown here
I think was acutally responding to not you . Are issues that have been around for a while less likely to be voted on?
Opps, more than one Jason maybe, it could go either way. You could always vote on this though and it's only received 7 over the past 2.5 years. I just think it's not that popular of a request or it would have more.
I had the same issue as , and couldn't find an extension, so I cobbled something together myself. It relies on the Custom CSS and JS Loader extension (). It's a small script which will dim either the editor window(s) or the terminal, depending on which one has the focus. I hardly start typing in the wrong window anymore. :-) If anybody is interested, just let me know.
I am highly interested.
Hi It's not 100% perfect, but close to 90%. :-) This is the trick: Download and install the Custom CSS and JS Loader extension.

Create a file vscode-custom- (or any name you'd like) in a folder on your system, with the following content: / var addon = "[inactive-window-dimmer]: " // Add event listener to all existing elements var allElements = document.querySelectorAll("*") for (element of allElements) { element.addEventListener("focusin", doDimWindow) } function doDimWindow() { // Primary elements var terminalElements = document.querySelectorAll('.terminal') // Terminal window var editorElements = document.querySelectorAll('.monaco-editor') // Editor window // Get currently active element var currentElementName = document.activeElement.className // Logging for debugging // (addon + "Selected element: " + currentElementName) // Don't do anything when elements like the menu bar or input fields are selected var regex = /actions-containerinput$/ if ((currentElementName) !currentElementName) { return } // Dim values (50%, 100%) var transparencyArray = [0.5, 1] // Check if something other than the terminal was activated, and if so, flip the values: Editor will be dimmed, terminal will be undimmed if (currentElementName !== "xterm-helper-textarea") { transparencyArray.reverse() } // Change opacity of the editor window for (element of editorElements) { = transparencyArray[0] } // Change opacity of the terminal window for (element of terminalElements) { = transparencyArray[1] } } Add the following to your , with the proper locations to the custom .js. "vscodecustomcss.imports": [ "file:///D:/OneDrive/Visual%20Studio%20Code/vscode-custom-", "file:///D:/OneDrive/Visual%20Studio%20Code/vscode-custom-" ], "": true, "vscodecustomcss.statusbar": false, (The .css file is not used in this scenario.) Issue the F1 command 'Reload Custom CSS and JS' and you should be good to go. :-) This reload needs to be done every time VSCode gets an update to a new version. You will also get a warning your VSCode installation is corrupted, which you can set to not display again. Both are behavior by design from the extension. Overall, it works pretty well.

If you use split editors or terminals, it will always (un)dim both panes, but I don't use splitting, so it's not a problem for me. Let me know if you found it useful. :-) (Something going wrong with the formatting of the code...)
So where do we vote on this?
My understanding is that you thumbsup the first post in this github thread (jasonhulbert's original post), or, more generally, the thread for the feature you're voting for (I'm not part of the VSCode team, but info found here )
This would be such a nice feature to have. It is somewhat hard to determine what "pane" is currently active when cursor is set to , even if it is blinking. I do prefer this style of the cursor but not having any instant understanding of where I am after doing one of the shortcuts is kind of confusing.
If you're trying to use custom JS above and finding it doesn't quite work exactly right with terminals being allowed in editor groups now, here's a modified version I came up with that seems to work:
I an additional slight modification to code so that all editors and terminals in a window dim if a window loses focus (so I can tell which window has focus if I have multiple windows open.
I modified the modification of the modified code to instead show a border around the editor, panel, and sidebar views: New to JS so if anyone can improve the efficiency of this, please do.
I made a suggestion to add a theme option: , i also made a suggestion to hide the cursor:
That's a easy problem to fix, and it does a lot for usability, please consider it for the next vscode update
We're moving back to a rectangle outline for the unfocused terminal, so that it's possible to differentiate regardless of cursor style. It's best if we can avoid adding yet another setting and I think this solves the issue for the most part.
I don't think that issue is really solved at all in this case is it? It has just been decided not to address it?
yes sorry, commented in the wrong tab
No worries, I was just surprised! :)
The PR you linked is about the cursor, how does that affect the terminal region?

I agree with you, less setting to manage is better for both the user and the dev team, the default should be designed to be good enough with usability in mind
If someone is still looking for a simple way to dim the unfocused Terminal using , this got the job done for me:
This is closed but i dont see this happening in latest insider Is there any configuration for this?
the current setting is "accessibility.unfocusedViewOpacity`. To improve discoverability, did you look for a setting and if so where did you search and what words did you use?
I looked under "inactive," "pane," "panel," and "dim." (I assumed it was going to be a boolean rather than a number.) Would never have occurred to me to look under "accessibility," as this seems not like an accommodation for someone who needs it but rather a display preference for everyone.
thanks, I'll tweak the description to include more keywords. I put it under accessibility as it makes it much clearer what element is focused, similar to the high contrast focus border in HC themes.
Sorry, I thought its a toggle dim/inactive unfocused terminal something like this I think instead of putting it under accessibility it should be a generic setting and shouldn't it be a default behaviour with just toggle with preset opacity and have optional property to set the opacity? Anyways thanks Appreciate your work!
cc about the setting name if you have opinions. Note that it's workbench-level, not editor. Thanks for the feedback. The rationale there is that 1 setting is simpler than 2, we typically combine settings where they can be naturally like this.
Name is ok, but users will expect that all views and editors will support this, Is that on the radar? To turn the feature on of, a Boolean would be more intuitive. The opacity as such can be a secondary setting. I personally would try to come up with a good default and only add a setting if multiple users ask for it.
Not so sure about this.

The ask is mainly to make clear whether a terminal or editor has focus, dimming the explorer also for example would make the experience worse imo Reopening to tweak the setting
As someone who's wanted this feature for a long time, I agree that the problem this is solving is really restricted to the editor and the terminal (i.e., the places where you're normally typing stuff), to prevent typing in the wrong spot. P.S. While I'm here, I'll just make one more plea for this not being buried in accessibility settings. I'm guessing I'm not the only person who zips right by those (both in the settings json and in release notes), assuming they don't apply to me. I understand your reasoning that this might help someone with visual challenges, but then again, so might font size, and that's not an accessibility setting. I just think moving it into regular settings makes it a lot more discoverable. In any case, thanks again for implementing this - looking forward to it being released!
do you have example(s) on what you would expect the setting to be called?
Hmmm... I want to say or , but I recognize that that's not 100% accurate, given that neither sidebar is affected (and those both count as views, correct?). Maybe one option would be to use that and have the options be , (default), or (with an explanation similar to that in that the panel is where the terminal, etc live). That way, if you ever do decide to extend this to other views, they can just be to the object option rather than having to spawn another option name. (There's precedent for settings being either a boolean or an object in , for example.) Thanks for considering this!
Completely agree. :-) Concerning the name, maybe something like ? Since both the editor and the terninal are the areas you do your real work in? Though it's not a term many people will search for. But I think most people would search for 'dim'. I don't think many people would search for 'opacity'. Using 'Inactive' instead of 'Unfocused' would be more in line with other settings I think (like or and all the other color/border settings).
Yes, I actually like better also, as I agree it's significantly more intuitive - was just trying to match the current name of .

But given that there's precedent for , I'd vote for that over .
I considered inactive but problem with it is that technically there is an active terminal when the editor is focused and vice versa. This is just a technical thing, but regardless mixing these terms could be confusing:
Thanks for the discussion all, I tweaked the settings in
Yay! Thanks, for taking our input!
I just checked The issue with this is If I enable this setting and If I do some changes in editor and click on other file from the explorer it just move the focus from the editor I don't think we want this behaviour I just care about the terminal and editor If I jump in between those then only it should inactive the corrosponding part but if it is going move the focus even if I click on the file explorer doesn't going to help much atleast for me
I think you're asking for us to track whether the terminal or editor was focused last which is more state than I'd prefer to track for this feature. I'll wait for more feedback on the topic to see the reception as is first.
Oh, damn, I hadn't even thought of this. Yeah, that's not exactly how I was picturing it, either. That said, I think it's worth turning it on and living with it for a few weeks. It may turn out to be intuitive, or it may not. And if it's not, we can always open another feature request!
Also a little tip, you can double click to select the file in the explorer and focus the editor
FYI I'm planning on moving this back to live under , see and some discussion about the feature in
There's been a bunch of feedback from the team during the test round. I'll be announcing the feature in the release notes' experimental section and this is the plan for upcoming improvements Feedback is welcome of course!
I like your system of making an issue specifically for internal testing and then linked issues for feedback! I may suggest it to our product team.
this is our "endgame" week where the whole team turn into testers for a bit , it certainly works pretty well when building devtools
Nice - I didn’t realize it was documented. Will definitely pass that along, thanks! And we do indeed make a devtool - you should sometime!
ah I think I've heard ads for Sentry and been at the same conferences.

I remember seeing
Oh, how funny, and man, what a throwback! I remember the day our head of design was figuring out how to make the "Sentry" on that hot dog swag. ! In any case, we have an as well as freestanding and SDKs (which, full disclosure, I helped maintain for a few years) should y'all ever be interested.