Terminal: Feature Request: Standard Opacity options like the traditional console.

It's not supported right now, but it's definitely something we don't want to lose track of. We'll need to do a bit of heavy lifting to get the composition visuals set up right, but it is "in plan."

See also #593, which has additional info.

I like classic transparency, but never used acrylic, one of the must-have feature for me :)

+1 on this!

Please do not "+1" issues, it creates unnecessary noise. There's a perfectly good +1 button right here:

@zadjii-msft with microsoft there is no such thing as a "perfectly good +1 button", even when making noise nobody really cares or listens to anything. I guess anyone who has ever used any Microsoft product knows this.

But hey, I do get the point. Sorry.

@TCB13 Just so you know, we're all actual people here sitting in our offices looking at our inboxes, and our triage queue, and the github issues list. We're reading each one of these issues, and we _feel things_ about them and the things people say in them. Please try to avoid being mean.

@DHowett-MSFT @zadjii-msft

The fact that acrylic was included instead of opacity really means that nobody actually considered the usability of this terminal. Looks to me that some PM just said "oh transparent things look cool, lets make it even cooler and add a blur to it!". Terminal apps / windows aren't usually transparent because it looks great, they are transparent because it allows you to see other stuff behind the window - an useful feature as most user will agree.

Maybe you should ask the other actual people in your company why I was so aggressive in my other comment. :)

@TCB13 there were voices asking for Acrylic to be added to the Command terminal, and at the time it was not possible for backwards compatibility reasons, but a new Terminal makes that possible.

The issue with this new version is that Opacity is not immediately possible with the new Windowing APIs which this is using, and is something the team is aware of, and will try to make possible.

There is no need to be so dismissive, just because it is not a feature you personally want or need.

This would be very useful.

In addition to what's already been said, the ability to have the window acrylic when focused and transparent when unfocused would be very nice as it would make that transition less jarring.

agreed. I personally want the regular opacity setting because I like very dark backgrounds with a slight transparency. When I tried using the acrylic options it made the background too bright for my liking. I'm a vampire I guess 🤷‍♂.

Glad to hear that it's at least planned. Thanks for making this tool and I look forward to future releases with more features like this one.

agreed. I personally think that the window turns straight to solid color suddenly when it loses focus. Traditional transparency is a better transition
Glad to hear that it's at least planned. Thanks for making this tool and I look forward to future releases with more features like this one.

The true is, that I will not use console, when there will not be classic transparency :), it's one must to have feature for me :)

this is not related to this issue but rather to sets of posts.

for cmd, I prefer 80% to 95% opacity, i.e, transparency. they are the same thing.

acrylic is translucency, I think. I will have to test as I disable it on all Windows machines that I use.

regards ratatoeey

So for the record, I've played with this. A rudimentary implementation isn't super tricky, but it's not... polished. The entire window becomes equally transparent including XAML controls (tab row, dialogs, etc.). I think from an architecture standpoint, it would be exceptionally tricky to try and get _just_ the "Terminal" content transparent, and even then, all Panes would be equally transparent, including separators, and dialogs would also still be transparent.

Weirdly enough, the MenuFlyout for the new tab dropdown _doesn't_ become transparent, which raises more questions.

Honestly in _my_ opinion, the experience feels a little unpolished. If this is what people really want, I'm not going to say no, but I also want to make sure we're shipping something high quality. Hence why I'm leaving it on the backlog, to try and find a _better_ solution.

Actually, I like the non-client regions transparent. That's how cmd works, and has for a while (maybe RS5?):

Honestly in _my_ opinion, the experience feels a little unpolished. If this is what people really want, I'm not going to say no, but I also want to make sure we're shipping something high quality. Hence why I'm leaving it on the backlog, to try and find a _better_ solution.

I quite like this effect - the only solid windows I want are dialogs & dropdowns - now I suppose I just need to build this from source :-/

Thanks for linking to the modification!

Yeah, I also think that everything transparent is a feature and not a bug 😄

The way cmd does it is very useful because you can read what is beneath (of course it depends on the transparency level to looks "good").

I would strongly suggest that the devs look at the functionality of gnome-terminal wrt transparency as a guide. For my part, I don't have a use for Acrylic and its fuzziness. I want it transparent so I can see through it, whether it's focussed or not. Thanks.

So for the record, I've played with this. A rudimentary implementation isn't super tricky, but it's not... polished. The entire window becomes equally transparent including XAML controls (tab row, dialogs, etc.). I think from an architecture standpoint, it would be exceptionally tricky to try and get _just_ the "Terminal" content transparent, and even then, all Panes would be equally transparent, including separators, and dialogs would also still be transparent.

It's ok to have the tab bar transparent, the whole window has to be transparent, with scrollbars too.
Much better would be to have little more transparency for terminal content, than for tab bar and statusbar, eg about 10%, but this has lower priority and it's not substantial.
Modal dialogs have to be opaque, nobody wants to have transparent dialogs. 🙂
Ideal would be to have different transparency for text and background, the text should be a little less transparent than the background, to make it easier to read.

The essential thing here is to make it look good. 🚀

Weirdly enough, the MenuFlyout for the new tab dropdown _doesn't_ become transparent, which raises more questions.

This is ok, this dropdown or flyout menus don't have to be transparent, it's much better to have them opaque.

Honestly in _my_ opinion, the experience feels a little unpolished. If this is what people really want, I'm not going to say no, but I also want to make sure we're shipping something high quality. Hence why I'm leaving it on the backlog, to try and find a _better_ solution.

You have to little play with it, purple background is not good example for a transparent background, it looks much better with black background.
Some examples 1, 2.

If you set up good and balanced transparency for a terminal, it can help you in some scenarios, in my workflow it helps me in 5-10% cases, when I don't have to switch to the underlying window. This is good from a practical point of view and added value is that it looks good. 🙂

Here is a link to code, how it is implemented in conemu.

@zadjii-msft I would be totally fine with your experimental transparency if it were implemented as in my suggestion
focused - useAcrylic
unfocused - use transparency

https://github.com/microsoft/terminal/issues/4413

From left
standard CMD with transparency, focused terminal, background terminal

Can u please add.a different options for transparent background and text(foregorund)
I don't want transpanent text. It's hard to read. But I want transpanent background

@zadjii-msft @cinnamon-msft

I'd like a Peek button on the TitleBar near the new tab + button or the minimize - button, just like Aero Peek.

If you guys are redoing the composition work then please consider adding it to the TitleBar. So that when I hover over it, I can see the screen behind, rather than staying transparent all the time.

__Relatively Related__

Can we have a Fullscreen button on the TitleBar on all apps that allow maximize (yes in terminal too)! I think we should add Peek to the list too IMHO, if we're adding in the Windowing system itself.

@Nirmal4G I've moved your first request to #5426. I'm pretty sure there's nothing we can do about your second request - that sounds like a pretty extensive change to the windowing of _all_ Windows applications. It might be a request that would fit in well over at Microsoft/PowerToys. IIRC, one of the original powertoys worked by modifying the titlebar caption buttons

Since this seems to be the catch-all issue for transparency and acrylic... I just installed this Notepads App that some other MSFT guy did in his spare time, and it seems to be able to maintain acrylic transparency while unfocused in background. It's using XAML and Windows.UI, too.

Please add this capability, too, at some point. Thanks.

The project page: https://github.com/JasonStein/Notepads

--edit:
Skimming over the project, he's doing his own custom Acrylic brush for all of this:

https://github.com/JasonStein/Notepads/blob/58530f19dd0173bab13e40c9511e5277e42c4129/src/Notepads/Brushes/HostBackdropAcrylicBrush.cs

I don't think they're saying they can't keep it acrylic when unfocused, they're saying they've decided not to as a broad company wide design decision in order to save battery life.

Yeaaaa, well... Transparency/acrylic in the terminal is the sort of eye candy that the user probably expects to be there all the time. Otherwise no one would want it, because having it while it's focused doesn't do that much in that regard.

Also, terminal users are likely advanced users, also considering actually needing to edit a JSON to enable it, and would probably be aware of the battery impact in some fashion.

Could still make it optional.

@ future self:

• https://github.com/JasonStein/Notepads/blob/58530f19dd0173bab13e40c9511e5277e42c4129/src/Notepads/Brushes/HostBackdropAcrylicBrush.cs
  
  
  
  • Shoot, this is using Win2D, which I'm not sure we can use, since it's C#
  
  
  • https://github.com/microsoft/Win2D/blob/master/winrt/docsrc/CanvasDevice.xml / https://microsoft.github.io/Win2D/html/M_Microsoft_Graphics_Canvas_CanvasDevice_GetSharedDevice.htm
  
  
• There is however https://docs.microsoft.com/en-us/uwp/api/windows.ui.composition.compositor.createhostbackdropbrush?view=winrt-18362
  
  
  
  • this looks promising
  
  
• https://stackoverflow.com/questions/43208841/how-to-use-acrylic-accent-createhostbackdropbrush-in-windows-10-creators-upd/44576160
• Then we'll write some code

            auto rootVisual = winrt::Windows::UI::Xaml::Hosting::ElementCompositionPreview::GetElementVisual(RootGrid());
            auto compositor = rootVisual.Compositor();
            auto rootSprite = compositor.CreateSpriteVisual();
            rootSprite.Size(winrt::Windows::Foundation::Size(
                ::base::saturated_cast<float>(RootGrid().ActualWidth()),
                ::base::saturated_cast<float>(RootGrid().ActualHeight())));

            auto b = rootVisual.Compositor().CreateHostBackdropBrush();

            rootSprite.Brush(b);
            winrt::Windows::UI::Xaml::Hosting::ElementCompositionPreview::SetElementChildVisual(RootGrid(), rootSprite);

• Oh no, even with this, we get pre-blurred content
  

• Which leads me to https://github.com/Microsoft/WindowsCompositionSamples/issues/202

• Which brings me full circle to the investigation I already did on this last year https://github.com/microsoft/terminal/issues/1753#issuecomment-508070516

I'm not promising anything here, just leaving notes from the tab's I've got open this morning

Wait, did I read it correctly? Having a partially transparent window or an acrylic without blur is not doable because of security issues? What?

I, like many, quite desperately want/need a terminal semi-transparency like it's been in use on the *nix front in ages. Do we really have to go the "screensaver route", capture the screen during painting, paint the capture as a background image in the window, and then paint the opacity on top of it?

I mean, how feasible could a semi-transparent window be a vector for an attack… even a fully transparent keylogger would deactivate the window. Genuinely curious. And baffled. But mostly curious.

Granted, that thread's pretty old, from a time when the only way to do Acrylic was from a pure UWP application. UWPs are pretty highly insulated against being able to read the state of other processes on the system. If an app in this context could trivially ready the contents of the window behind it, then it could theoretically read the contents of anything else that's running on the system, in _any_ context. This is something that's absolutely not possible for UWP apps.

The world has changed a lot since then - there's apps like the Terminal that use UWP XAML (and acrylic) but _aren't_ UWP applications. In this new model, it might be possible for us to do something differently, we just need to do more research.

Reading through the source for the AcrylicBrush, I may have found a workaround. But do take this with a grain of salt as I have minimal experience with windows UI development.
It looks like a factory method in the Acrylic Brush has support for pre-blurred backgrounds, seemingly where the shell would have already done it, IF that method is exposed and IF a non-blurred background is passed as a pre-blurred background and IF I'm not totally off the mark here, the factory might not add a blur effect whatsoever. But again, I have a high chance of being 150% wrong here so, take that as you will.

OMG, this discussion is more than an year old, but essential Glass Transparency is still not implemented. It is standard for unix terminals.

@alxkvx As discussed in this thread at great length, this is a technically hard problem, hence why it still hasn't been implemented. If you've got any suggestions as to _how_ this could be implemented with our UI stack, I'd be happy to hear them.

@alxkvx As discussed in this thread at great length, this is a technically hard problem, hence why it still hasn't been implemented. If you've got any suggestions as to _how_ this could be implemented with our UI stack, I'd be happy to hear them.

well, i didn't dig into the problem actually, And i dont understand why UI stack has problems with that, i know that using WSL terminal i can just right click > Properties > Set Opacity and i will get glass transparency. For me personally this is essential feature.

The blur and going opaque when the terminal isn't focused is just silly. Who asked for this? 🤷 I'll keep using cmd and powershell.

@alxkvx As discussed in this thread at great length, this is a technically hard problem, hence why it still hasn't been implemented. If you've got any suggestions as to _how_ this could be implemented with our UI stack, I'd be happy to hear them.

well, i didn't dig into the problem actually, And i dont understand why UI stack has problems with that, i know that using WSL terminal i can just right click > Properties > Set Opacity and i will get glass transparency. For me personally this is essential feature.

The issue is that the UI framework (UWP XAML) that Windows terminal is built in simply does not support full transparency like win32 or WPF apps (e.g. wsl terminal). The only tool they have access to is Acrylic which is meant less for transparency and more as a design accent. Implementing it under their UI stack would take a hacky solution like my above comment or a total reworking of how the console is rendered (at least that's my understanding, windows UI isn't my field of development)

Edit: clarification

@alxkvx As discussed in this thread at great length, this is a technically hard problem, hence why it still hasn't been implemented. If you've got any suggestions as to _how_ this could be implemented with our UI stack, I'd be happy to hear them.

well, i didn't dig into the problem actually, And i dont understand why UI stack has problems with that, i know that using WSL terminal i can just right click > Properties > Set Opacity and i will get glass transparency. For me personally this is essential feature.

The issue is that the UI framework (XAML) that Windows terminal is built in simply does not support full transparency like win32 apps (e.g. wsl terminal). The only tool they have access to is Acrylic which is meant less for transparency and more as a design accent. Implementing it under their UI stack would take a hacky solution like my above comment or a total reworking of how the console is rendered (at least that's my understanding, windows UI isn't my field of development)

Xaml does support transparency, but UWP windows and Xaml Islands does not.

When Terminal is able to move over to WinUI 3 Desktop, and can tap into the HWND itself, then it will be able to implement a non-blurred Transparency.

Acrylic itself will be delayed for WinUI 3 - as they have to re-work it whilst extracting it from the OS

Wait no, lets clear up some misconceptions - We're already able to access the HWND directly, because we're already a win32 app. We're working with the XAML and composition teams to try and figure out a solution to this. From my understanding (currently), the XAML Island always has an opaque background, which means that we can't just have transparent components in XAML that are transparent all the way through to the HWND. I have no idea if WinUI 3 will magically solve this for us, which is something we'll need to discuss more with that team. Fortunately, they work in the hallway next to us (or at least they did when we all worked in office buildings), so having these discussions isn't too hard 😄

@ future self:

• https://github.com/JasonStein/Notepads/blob/58530f19dd0173bab13e40c9511e5277e42c4129/src/Notepads/Brushes/HostBackdropAcrylicBrush.cs

  • Shoot, this is using Win2D, which I'm not sure we can use, since it's C#

I am pretty sure Win2D supports c++/winrt (its written in c++!), but even if not for this use case there is this:

https://github.com/fobrs/Win2DinMFC

Also, I believe custom acrylic should be possible because I was able to achieve acrylic (with rounded corners!!!) in WPF , by following this sample:

https://github.com/microsoft/Windows.UI.Composition-Win32-Samples/tree/master/dotnet/WPF/AcrylicEffect

And this post is phenomenal:

https://notes.yvt.jp/Desktop-Apps/Enabling-Backdrop-Blur

Those are all really helpful if you're using WPF XAML, but we're using UWP XAML, which will unfortunately always have the opaque backdrop. We're working with the WinUI team to hopefully get that restriction relaxed for WinUI 3.0. There might be a while before there's any other progress on this issue, while we work on the technical specifics with them.

@zadjii-msft So, you are telling me the wpf control of terminal could possibly support acrylic blur customizable acrylic, but not the UWP one(for the foreseeable future)...weird times 😅😅

Oh no the UWP XAML one can support acrylic just fine, it's just "traditional opacity" (opacity without the acrylic effect) that the UWP XAML one can't support currently.

I'd love for you to continue this discussion elsewhere (perhaps file a new issue if you have a problem?) because this is the thread for _non-blurry transparency_. We already have "acrylic" in the UWP control, and further discussing "how to get acrylic in the UWP control" is ... I mean, like, trying to explain to a horse how it could become a horse if it really, really wanted to?

@zadjii-msft @DHowett Sorry, I didn't mean that. By acrylic I meant acrylic with customizable blur radius

@zadjii-msft I want to do some experiments, can you point me where the xaml hosting window/DesktopWindowXamlSource is created in your code? Its a very large codebase 😅😅

@AnuthaDev It's in src/cascadia/WindowsTerminal/IslandWindow.cpp

Okay, its atleast possible for wpf for sure:

Maybe the window in IslandWindow.cpp can be created with WS_EX_NOREDIRECTIONBITMAP and the method followed here can be used to create a non blur acrylicbrush. Using createhostbackdropbrush() introduces blur automatically, so createbackdropbrush() is the only option. Or maybe it won't work,... idk. Will try and let you know....

Edit: Narrator: It didn't work!

Maybe the window in IslandWindow.cpp can be created with WS_EX_NOREDIRECTIONBITMAP and the method followed here can be used to create a _non blur_ acrylicbrush. Using createhostbackdropbrush() introduces blur automatically, so createbackdropbrush() is the only option. Or maybe it won't work,... idk. Will try and let you know...

I don’t think so as that method is under WPF. XAML is used in two different frameworks WPF (that method) and UWP (used in WT). I’ve poked around in the source for UWP acrylic, and the only thing that could possibly get traditional transparency working is a really Hakki workaround where are you basically trick the OS into thinking that the background has already been blurred so it doesn’t have to add a blur itself, but I’m pretty tree even that isn’t compatible with XAML islands.

@zadjii-msft @DHowett Okay, so here is what I found:
It is certainly possible to get a custom blur acrylic in a c++ win32 app using win2d:

(Blur radius 1):

HOWEVER!! You cannot do so with xaml islands. As you already know there will definitely be an opaque background behind xaml...

To do this we need to use composition apis and render to a hwnd DesktopWindowTarget.

Therefore, as it currently stands, to get non blur acrylic transparency we would need to remove xaml islands and use this instead of a swapchainpanel.

(If you already know this, sorry for wasting your time...)

Hence, no transparency without a significant architecture change.

(A conclusion that was already apparent and to which I contributed absolutely nothing😅😅)

Yeah, so TLDR for anyone who doesn’t want to read all of the previous discussion is basically that the framework that is used for windows terminal does not currently support this feature HOWEVER development on that framework is ongoing and transparency (as far as I understand it) is in the works. So only once the framework (XAML islands) supports transparency can this issue be started on.

Yeah, so TLDR for anyone who doesn’t want to read all of the previous discussion is basically that the framework that is used for windows terminal does not currently support this feature HOWEVER development on that framework is ongoing and transparency (as far as I understand it) is in the works. So only once the framework (XAML islands) supports transparency can this issue be started on.

i wonder why transparency feature was not included initially in that project and was not considered when UI engine was chosen. Having 10+ years working with Linux terminals, all have that feature and it is actively used by many users. Strange for me.

Powershell & CMD have the option to set transparency. I understand that technologies used are different but many users use transparency configs

Powershell & CMD have the option to set transparency. I understand that technologies used are different but many users use transparency configs

yea, the same as WSL terminal

The CMD and PWSH transparency is achievable with this terminal, but from what I gather the majority of people (myself included) don't want that version of transparency, rather a *nix-like terminal transparency, where only the background is translucent instead of everything, text included.

Also, there are some hackish ways to fake transparency, with a screen RECT grab, painted over the terminal itself, and then painting a semi transparent color over, but even in that there are limitations and pitfalls.

Maybe this can be implemented by creating a window below (alongside?) the xaml islands window (with the parent window set to WS_EX_NOREDIRECTIONBITMAP) and setting WS_CLIPSIBLINGS on it, then composition api and directx interop can be used to render content with translucent background (Like so) to this window. So, you wouldn't need to remove xaml islands and stuff like scrollbars should still work, just the swapchainpanel part would be replaced. Or maybe if that doesn't work, you could cut a hole over the swapchainpanel part using HRGN, so the composition window below it becomes visible. There shouldn't be any noticeable performance regression moving from swapchainpanel to a hwnd (probably)

The problem with pursuing a hackey workaround is that it is hackey and inherently prone to bugs. WinUI 3 will most likely support the proposed functionality so there are plans for implementing it, it’s just a waiting game for the official tool chain to support it. The devs have already confirmed that they are directly collaborating with the WinUI team on this.

(A conclusion that was already apparent and to which I contributed absolutely nothing😅😅)

I wouldn't say that you contributed nothing - I'm always happy to have external confirmation of my own research. I would have been even happier if you had proven me wrong and found an effective way to do this 😉

As mentioned before in this thread - We're working with the WinUI team to get this added in to WinUI 3.0. I believe this is being tracked in https://github.com/microsoft/microsoft-ui-xaml/issues/1247. This is the path we'll be pursuing to get this feature added to the Terminal, because driving this solution also means driving an important dev platform feature for the entire platform, one that'll help improve other applications on Windows as well.

As mentioned before in this thread - We're working with the WinUI team to get this added in to WinUI 3.0. I believe this is being tracked in microsoft/microsoft-ui-xaml#1247. This is the path we'll be pursuing to get this feature added to the Terminal, because driving this solution also means driving an important dev platform feature for the entire platform, one that'll help improve other applications on Windows as well.

Since the terminal team has chosen a direction on this one, should the "help wanted" tag be removed?

@tajetaje good catch, thanks!

(A conclusion that was already apparent and to which I contributed absolutely nothing😅😅)

I wouldn't say that you contributed nothing - I'm always happy to have external confirmation of my own research. I would have been even happier if you had proven me wrong and found an effective way to do this 😉

As mentioned before in this thread - We're working with the WinUI team to get this added in to WinUI 3.0. I believe this is being tracked in microsoft/microsoft-ui-xaml#1247. This is the path we'll be pursuing to get this feature added to the Terminal, because driving this solution also means driving an important dev platform feature for the entire platform, one that'll help improve other applications on Windows as well.

@zadjii-msft, I can see how WinUI would play a part in this, but not sure how the borderless issue gets us there. In terms of the actual result most people are after, I think this is a beautiful rendition from @mdtauk (#743) of what could be:

(A conclusion that was already apparent and to which I contributed absolutely nothing😅😅)

I wouldn't say that you contributed nothing - I'm always happy to have external confirmation of my own research. I would have been even happier if you had proven me wrong and found an effective way to do this 😉
As mentioned before in this thread - We're working with the WinUI team to get this added in to WinUI 3.0. I believe this is being tracked in microsoft/microsoft-ui-xaml#1247. This is the path we'll be pursuing to get this feature added to the Terminal, because driving this solution also means driving an important dev platform feature for the entire platform, one that'll help improve other applications on Windows as well.

@zadjii-msft, I can see how WinUI would play a part in this, but not sure how the borderless issue gets us there. In terms of the actual result most people are after, I think this is a beautiful rendition from @mdtauk (#743) of what could be:

https://github.com/microsoft/microsoft-ui-xaml/issues/1247 tracks both borderless and transparency