Feature Request: Standard Opacity options like the traditional console. #868

@TCB13 commented on GitHub (Jul 2, 2019):

+1 on this!

@TCB13 commented on GitHub (Jul 2, 2019): +1 on this!

claunia commented

@zadjii-msft commented on GitHub (Jul 2, 2019):

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

@zadjii-msft commented on GitHub (Jul 2, 2019): Please do not "+1" issues, it creates unnecessary noise. There's a perfectly good +1 button right here: ![image](https://user-images.githubusercontent.com/18356694/60544971-8b497d00-9cdf-11e9-88ca-519566f7ad44.png)

claunia commented

@TCB13 commented on GitHub (Jul 2, 2019):

@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 commented on GitHub (Jul 2, 2019): @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.

claunia commented

@DHowett-MSFT commented on GitHub (Jul 2, 2019):

@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 commented on GitHub (Jul 2, 2019): @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.

claunia commented

@TCB13 commented on GitHub (Jul 3, 2019):

@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 commented on GitHub (Jul 3, 2019): @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. :)

claunia commented

@mdtauk commented on GitHub (Jul 3, 2019):

@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.

@mdtauk commented on GitHub (Jul 3, 2019): @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.

claunia commented

@iCodeSometime commented on GitHub (Sep 9, 2019):

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.

@iCodeSometime commented on GitHub (Sep 9, 2019): 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.

claunia commented

@lkspencer commented on GitHub (Sep 21, 2019):

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.

@lkspencer commented on GitHub (Sep 21, 2019): 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.

claunia commented

@oneliey commented on GitHub (Oct 26, 2019):

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.

@oneliey commented on GitHub (Oct 26, 2019): 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.

claunia commented

@silverqx commented on GitHub (Oct 26, 2019):

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 :)

@silverqx commented on GitHub (Oct 26, 2019): 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 :)

claunia commented

from https://github.com/microsoft/terminal/issues/603#issuecomment-529696036,

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

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

CLICK ME

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

when people are seem to be way out of touch with the common expectations of majority of app users, they get passionate responses.

and transparency has been available for a long time, so its not a single person pressuring the devs to please one single person. as your last statement implies, for some reason; feel free to edit it.

maybe TCB13 was rude or aggressive in some other thread or occassion? as its mostly harmless hyperbole in https://github.com/microsoft/terminal/issues/603#issuecomment-508031247

also, silverqx, see https://github.com/microsoft/terminal/issues/603#issuecomment-546613996 https://github.com/microsoft/terminal/issues/603#issuecomment-507248317 and how long it has been since https://github.com/microsoft/terminal/tags?after=RS2-final been since that first public release. It seems, it will take a long time.

don't do it twice, see https://github.com/microsoft/terminal/issues/603#issuecomment-507835880

iCodeSometime, no acrylic please. just let acrylic be invisible to those that want to use transparency. the way cmd handles it is nice.

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

@ghost commented on GitHub (Nov 11, 2019): this is not related to this issue but rather to sets of posts. <details> <summary>CLICK ME</summary> <p> > There is no need to be so dismissive, just because it is not a feature you personally want or need. when people are seem to be way out of touch with the common expectations of majority of app users, they get passionate responses. and transparency has been available for a long time, so its not a single person pressuring the devs to please one single person. as your last statement implies, for some reason; feel free to edit it. maybe TCB13 was rude or aggressive in some other thread or occassion? as its mostly harmless hyperbole in https://github.com/microsoft/terminal/issues/603#issuecomment-508031247 --- also, silverqx, see https://github.com/microsoft/terminal/issues/603#issuecomment-546613996 https://github.com/microsoft/terminal/issues/603#issuecomment-507248317 and how long it has been since https://github.com/microsoft/terminal/tags?after=RS2-final been since that first public release. It seems, it will take a long time. don't do it twice, see https://github.com/microsoft/terminal/issues/603#issuecomment-507835880 --- from https://github.com/microsoft/terminal/issues/603#issuecomment-529696036, iCodeSometime, no acrylic please. just let acrylic be invisible to those that want to use transparency. the way cmd handles it is nice. </p> </details> --- 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

claunia commented

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

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.

@zadjii-msft commented on GitHub (Nov 11, 2019): 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. ![image](https://user-images.githubusercontent.com/18356694/68593349-daa47480-045a-11ea-9ad7-3214a445ade5.png) Weirdly enough, the MenuFlyout for the new tab dropdown _doesn't_ become transparent, which raises more questions. ![image](https://user-images.githubusercontent.com/18356694/68593407-0293d800-045b-11ea-9ebe-ba311237c32b.png) 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.

claunia commented

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

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

@heaths commented on GitHub (Nov 11, 2019): Actually, I like the non-client regions transparent. That's how cmd works, and has for a while (maybe RS5?): ![image](https://user-images.githubusercontent.com/1532486/68614416-b1dda880-0475-11ea-953d-be6f6bc58c3e.png)

claunia commented

@Brassfield commented on GitHub (Nov 23, 2019):

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!

@Brassfield commented on GitHub (Nov 23, 2019): > 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!

claunia commented

@fhelwanger commented on GitHub (Nov 25, 2019):

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").

@fhelwanger commented on GitHub (Nov 25, 2019): 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").

claunia commented

@admered1 commented on GitHub (Jan 21, 2020):

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.

@admered1 commented on GitHub (Jan 21, 2020): 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.

claunia commented

@silverqx commented on GitHub (Jan 22, 2020):

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.

@silverqx commented on GitHub (Jan 22, 2020): > 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](https://i.stack.imgur.com/bjYQ1.png), [2](https://fedoramagazine.org/wp-content/uploads/2014/05/Screenshot-from-2014-05-15-173413.png). 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](https://github.com/Maximus5/ConEmu/blob/be9695f5b565c28379237a5fdea3abab7fea3e3a/src/ConEmu/ConEmu.cpp#L12824) to code, how it is implemented in conemu.

claunia commented

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

@ackvf commented on GitHub (Jan 30, 2020):

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

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

@ackvf commented on GitHub (Jan 30, 2020): @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 ![image](https://user-images.githubusercontent.com/2313018/73467282-699e9a00-4383-11ea-9871-5c3ac6d29afe.png)

claunia commented

@ilqvya commented on GitHub (Feb 3, 2020):

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

@ilqvya commented on GitHub (Feb 3, 2020): 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

claunia commented

@Nirmal4G commented on GitHub (Apr 18, 2020):

@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 commented on GitHub (Apr 18, 2020): @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.

claunia commented

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

@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

@zadjii-msft commented on GitHub (Apr 20, 2020): @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](https://github.com/microsoft/PowerToys). IIRC, one of the original powertoys worked by modifying the titlebar caption buttons ![image](https://user-images.githubusercontent.com/18356694/79763399-a7a7bc00-82e9-11ea-8d52-740a57887da6.png)

claunia commented

58530f19dd/src/Notepads/Brushes/HostBackdropAcrylicBrush.cs

@glowtape commented on GitHub (May 10, 2020):

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:

@glowtape commented on GitHub (May 10, 2020): 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

claunia commented

@iCodeSometime commented on GitHub (May 10, 2020):

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.

@iCodeSometime commented on GitHub (May 10, 2020): 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.

claunia commented

@glowtape commented on GitHub (May 10, 2020):

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.

@glowtape commented on GitHub (May 10, 2020): 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.

claunia commented

@zadjii-msft commented on GitHub (May 11, 2020):

@ future self:

58530f19dd/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

@zadjii-msft commented on GitHub (May 11, 2020): @ 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 ```c++ 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 ![image](https://user-images.githubusercontent.com/18356694/81589666-38206c00-937f-11ea-8884-c234d065dc1b.png) * 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

claunia commented

@Varstahl commented on GitHub (May 11, 2020):

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.

@Varstahl commented on GitHub (May 11, 2020): 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.

claunia commented

@zadjii-msft commented on GitHub (May 11, 2020):

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.

@zadjii-msft commented on GitHub (May 11, 2020): 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.

claunia commented

@jthoward64 commented on GitHub (May 22, 2020):

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.

@jthoward64 commented on GitHub (May 22, 2020): Reading through the [source for the AcrylicBrush](https://github.com/microsoft/microsoft-ui-xaml/tree/master/dev/Materials/Acrylic), 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](https://github.com/microsoft/microsoft-ui-xaml/blob/master/dev/Materials/Acrylic/AcrylicBrush.cpp#L798) 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.

claunia commented

@alxkvx commented on GitHub (May 26, 2020):

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

@alxkvx commented on GitHub (May 26, 2020): OMG, this discussion is more than an year old, but essential Glass Transparency is still not implemented. It is standard for unix terminals.

claunia commented

@zadjii-msft commented on GitHub (May 26, 2020):

@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.

@zadjii-msft commented on GitHub (May 26, 2020): @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.

claunia commented

@alxkvx commented on GitHub (May 26, 2020):

@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.

@alxkvx commented on GitHub (May 26, 2020): > @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.

claunia commented

@taylus commented on GitHub (May 26, 2020):

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.

@taylus commented on GitHub (May 26, 2020): 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.

claunia commented

@jthoward64 commented on GitHub (May 27, 2020):

@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

@jthoward64 commented on GitHub (May 27, 2020): > > @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

claunia commented

@mdtauk commented on GitHub (May 27, 2020):

@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

@mdtauk commented on GitHub (May 27, 2020): > > > @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

claunia commented

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

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 😄

@zadjii-msft commented on GitHub (May 27, 2020): 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 😄

claunia commented

https://github.com/fobrs/Win2DinMFC

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

@ future self:

58530f19dd/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:

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

@AnuthaDev commented on GitHub (Jun 11, 2020): > @ 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](https://github.com/windows-toolkit/Microsoft.Toolkit.Win32/issues/168) 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

claunia commented

@zadjii-msft commented on GitHub (Jun 11, 2020):

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 commented on GitHub (Jun 11, 2020): 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.

claunia commented

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

@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 😅😅

@AnuthaDev commented on GitHub (Jun 11, 2020): @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 😅😅

claunia commented

@zadjii-msft commented on GitHub (Jun 11, 2020):

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.

@zadjii-msft commented on GitHub (Jun 11, 2020): 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.

claunia commented

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

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?

@DHowett commented on GitHub (Jun 11, 2020): 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?

claunia commented

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

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

@AnuthaDev commented on GitHub (Jun 11, 2020): @zadjii-msft @DHowett Sorry, I didn't mean that. By acrylic I meant *acrylic with customizable blur radius*

claunia commented

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

@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 commented on GitHub (Jun 11, 2020): @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 😅😅

claunia commented

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

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

@beviu commented on GitHub (Jun 11, 2020): @AnuthaDev It's in `src/cascadia/WindowsTerminal/IslandWindow.cpp`

claunia commented

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

Okay, its atleast possible for wpf for sure:

@AnuthaDev commented on GitHub (Jun 11, 2020): Okay, its atleast possible for wpf for sure: ![Screenshot (363)](https://user-images.githubusercontent.com/36439704/84429049-2adbf300-ac45-11ea-8cb8-0119f328d3aa.png)

claunia commented

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

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!

@AnuthaDev commented on GitHub (Jun 11, 2020): Maybe the window in IslandWindow.cpp can be created with WS_EX_NOREDIRECTIONBITMAP and the method followed [here](https://github.com/microsoft/Windows.UI.Composition-Win32-Samples/blob/master/dotnet/WPF/AcrylicEffect/AcrylicEffect/CompositionHostControl.xaml.cs) 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!

claunia commented

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

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.

@jthoward64 commented on GitHub (Jun 12, 2020): > Maybe the window in IslandWindow.cpp can be created with WS_EX_NOREDIRECTIONBITMAP and the method followed [here](https://github.com/microsoft/Windows.UI.Composition-Win32-Samples/blob/master/dotnet/WPF/AcrylicEffect/AcrylicEffect/CompositionHostControl.xaml.cs) 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.

claunia commented

@AnuthaDev commented on GitHub (Jun 13, 2020):

@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...)

@AnuthaDev commented on GitHub (Jun 13, 2020): @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): ![Screenshot (364)](https://user-images.githubusercontent.com/36439704/84570100-938fb080-ada8-11ea-9893-15aab24d37b4.png) 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](https://docs.microsoft.com/en-us/windows/uwp/composition/composition-native-interop) instead of a swapchainpanel. (If you already know this, sorry for wasting your time...)

claunia commented

@AnuthaDev commented on GitHub (Jun 13, 2020):

Hence, no transparency without a significant architecture change.

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

@AnuthaDev commented on GitHub (Jun 13, 2020): Hence, no transparency without a significant architecture change. (A conclusion that was already apparent and to which I contributed absolutely nothing😅😅)

claunia commented

@jthoward64 commented on GitHub (Jun 13, 2020):

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.

@jthoward64 commented on GitHub (Jun 13, 2020): 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.

claunia commented

@alxkvx commented on GitHub (Jun 14, 2020):

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.

@alxkvx commented on GitHub (Jun 14, 2020): > 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.

claunia commented

@50l3r commented on GitHub (Jun 14, 2020):

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

@50l3r commented on GitHub (Jun 14, 2020): Powershell & CMD have the option to set transparency. I understand that technologies used are different but many users use transparency configs

claunia commented

@alxkvx commented on GitHub (Jun 14, 2020):

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

@alxkvx commented on GitHub (Jun 14, 2020): > 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

claunia commented

@Varstahl commented on GitHub (Jun 14, 2020):

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.

@Varstahl commented on GitHub (Jun 14, 2020): 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.

claunia commented

@AnuthaDev commented on GitHub (Jun 14, 2020):

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)

@AnuthaDev commented on GitHub (Jun 14, 2020): 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](https://docs.microsoft.com/en-us/windows/uwp/composition/composition-native-interop) can be used to render content with translucent background ([Like so]( https://github.com/microsoft/terminal/issues/603#issuecomment-643625234)) 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)

claunia commented

@jthoward64 commented on GitHub (Jun 14, 2020):

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.

@jthoward64 commented on GitHub (Jun 14, 2020): 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.

claunia commented

@zadjii-msft commented on GitHub (Jun 15, 2020):

(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.

@zadjii-msft commented on GitHub (Jun 15, 2020): > (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.

claunia commented

@jthoward64 commented on GitHub (Aug 21, 2020):

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?

@jthoward64 commented on GitHub (Aug 21, 2020): > 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](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. Since the terminal team has chosen a direction on this one, should the "help wanted" tag be removed?

claunia commented

@zadjii-msft commented on GitHub (Aug 21, 2020):

@tajetaje good catch, thanks!

@zadjii-msft commented on GitHub (Aug 21, 2020): @tajetaje good catch, thanks!

claunia commented

2026-01-30 22:07:27 +00:00

@Chiramisudo commented on GitHub (Sep 10, 2020):

(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:

@Chiramisudo commented on GitHub (Sep 10, 2020): > > (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](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. @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](https://github.com/microsoft/terminal/pull/743#issuecomment-492019264)) of what could be: > ![image](https://user-images.githubusercontent.com/7389110/57660081-c9c69380-75dc-11e9-9dc6-a45942a24307.png)

claunia commented

@jthoward64 commented on GitHub (Sep 10, 2020):

(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

@jthoward64 commented on GitHub (Sep 10, 2020): > > > (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](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. > > @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](https://github.com/microsoft/terminal/pull/743#issuecomment-492019264)) of what could be: > > > ![image](https://user-images.githubusercontent.com/7389110/57660081-c9c69380-75dc-11e9-9dc6-a45942a24307.png) https://github.com/microsoft/microsoft-ui-xaml/issues/1247 tracks both borderless and transparency

claunia commented

2026-01-30 22:07:27 +00:00

@loopervfx commented on GitHub (Dec 9, 2020):

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 😄

@zadjii-msft great to hear about this sort of inter-team communication. just goes to show how sociological (not just technological) building software really is. thank you for your continued work and navigating all the (sometimes very... passionate 😅) community feedback on this. 💞

@loopervfx commented on GitHub (Dec 9, 2020): > 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 😄 @zadjii-msft great to hear about this sort of inter-team communication. just goes to show how sociological (not just technological) building software really is. thank you for your continued work and navigating all the (sometimes very... passionate 😅) community feedback on this. 💞

claunia commented

2026-01-30 22:07:27 +00:00

@desmap commented on GitHub (Feb 17, 2021):

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.

I prefer full transparency because it gives a more consistent look and feel paired with still good readability.

Giving some elements transparency and some not looks less clean. The opacity level has to be of course right and then, things look really gorgeous. If you can change opacity on the fly things get even better, we did this in the other issue with AHK. I posted following screenshots there, here with some additional window behind just to show its visual power:

Here with a browser behind—pls zoom in to the native resolution to check the readability of both the vim welcome message and the Github issue in Chrome behind:

Just the wallpaper behind:

As said, if you set the opacity too low/the transparency too high, of course things will look messed up.

@desmap commented on GitHub (Feb 17, 2021): > 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. I prefer full transparency because it gives a more consistent look and feel paired with still good readability. Giving some elements transparency and some not looks less clean. The opacity level has to be of course right and then, things look really gorgeous. If you can change opacity on the fly things get even better, we did this [in the other issue with AHK](https://github.com/microsoft/terminal/issues/1753#issuecomment-778649347). I posted following screenshots there, here with some additional window behind just to show its visual power: Here with a browser behind—___pls zoom in to the native resolution to check the readability of both the vim welcome message and the Github issue in Chrome behind___: ![image](https://user-images.githubusercontent.com/43666255/108167420-f2ef4e80-70f5-11eb-86e2-d40872beccd6.png) Just the wallpaper behind: ![image](https://user-images.githubusercontent.com/43666255/108165591-1c5aab00-70f3-11eb-9e9d-327c0570ae31.png) As said, if you set the opacity too low/the transparency too high, of course things will look messed up.

claunia commented

2026-01-30 22:07:28 +00:00

@darkphase commented on GitHub (May 9, 2021):

How alacritty is doing that
https://github.com/alacritty/alacritty

@darkphase commented on GitHub (May 9, 2021): How alacritty is doing that https://github.com/alacritty/alacritty

claunia commented

2026-01-30 22:07:28 +00:00

@denodaeus commented on GitHub (May 30, 2021):

So basically, beyond the above hack that sometimes works with AHK, this issue has been open for 2 years, is one of the most often requested features in Issues that constantly get closed because of duplicates, gets handed off to a different team to implement of which is in the "Freezer" part of their backlog, so this feature probably isn't going to happen for another 3 years.

I've been tracking this feature now for more than a year, and it really is the single make it or break it feature keeping me from moving to terminal over Hyper.js -- but just seeing the back and forth between teams at Microsoft and now seeing this basically buried over on the microsoft-ui-xaml side for 2 years is incredibly dissapointing.

@denodaeus commented on GitHub (May 30, 2021): So basically, beyond the above hack that sometimes works with AHK, this issue has been open for 2 years, is one of the most often requested features in Issues that constantly get closed because of duplicates, gets handed off to a different team to implement of which is in the "Freezer" part of their backlog, so this feature probably isn't going to happen for another 3 years. I've been tracking this feature now for more than a year, and it really is the single make it or break it feature keeping me from moving to terminal over Hyper.js -- but just seeing the back and forth between teams at Microsoft and now seeing this basically buried over on the microsoft-ui-xaml side for 2 years is incredibly dissapointing.

claunia commented

2026-01-30 22:07:29 +00:00

@mdtauk commented on GitHub (May 30, 2021):

I think this requires WinUI 3 to be done before Terminal can have full ownership of the window transparency, but I may be mistaken.

One issue with full transparency, is accessibility concerns with contrast ratios. If the text could remain fully opaque, whilst background colours and window frames become translucent, this would be a better approach, and then transparency could be disabled with high contrast modes.

@mdtauk commented on GitHub (May 30, 2021): I think this requires WinUI 3 to be done before Terminal can have full ownership of the window transparency, but I may be mistaken. One issue with full transparency, is accessibility concerns with contrast ratios. If the text could remain fully opaque, whilst background colours and window frames become translucent, this would be a better approach, and then transparency could be disabled with high contrast modes.

claunia commented

2026-01-30 22:07:30 +00:00

@jthoward64 commented on GitHub (Jun 29, 2021):

I think this requires WinUI 3 to be done before Terminal can have full ownership of the window transparency, but I may be mistaken.

One issue with full transparency, is accessibility concerns with contrast ratios. If the text could remain fully opaque, whilst background colours and window frames become translucent, this would be a better approach, and then transparency could be disabled with high contrast modes.

Honestly with a developer app like terminal I think we can trust users to know that transparency can conflict (depending on config it can be fine) with high contrast. There are times that the UI/UX should restrict potentially bad experiences, but developer features are rarely the place to limit user freedom.

@jthoward64 commented on GitHub (Jun 29, 2021): > I think this requires WinUI 3 to be done before Terminal can have full ownership of the window transparency, but I may be mistaken. > > One issue with full transparency, is accessibility concerns with contrast ratios. If the text could remain fully opaque, whilst background colours and window frames become translucent, this would be a better approach, and then transparency could be disabled with high contrast modes. Honestly with a developer app like terminal I think we can trust users to know that transparency can conflict (depending on config it can be fine) with high contrast. There are times that the UI/UX should restrict potentially bad experiences, but developer features are rarely the place to limit user freedom.

claunia commented

2026-01-30 22:07:30 +00:00

@iCodeSometime commented on GitHub (Jun 29, 2021):

Agreed. Sounds like you're worried someone might choose to set their transparency to a setting that your team personally doesn't like.

This is a feature of every major terminal, and literally no one has a problem with this. Just do a few quick google searches

"I can't read my terminal"
"Terminal text too faint"
"Terminal too transparent"

There are none.

@iCodeSometime commented on GitHub (Jun 29, 2021): Agreed. Sounds like you're worried someone might _choose_ to set their transparency to a setting that your team personally doesn't like. This is a feature of every major terminal, and literally no one has a problem with this. Just do a few quick google searches - "I can't read my terminal" - "Terminal text too faint" - "Terminal too transparent" There are none.

claunia commented

2026-01-30 22:07:30 +00:00

@jthoward64 commented on GitHub (Jun 29, 2021):

Agreed. Sounds like you're worried someone might choose to set their transparency to a setting that your team personally doesn't like.

This is a feature of every major terminal, and literally no one has a problem with this. Just do a few quick google searches

"I can't read my terminal"

"Terminal text too faint"

"Terminal too transparent"

There are none.

a little harsh, but nonetheless yeah that's what I was getting at. On the other hand if WT does become the default terminal some kind of accomidation might be a good idea. My commend only applies if WT remains a dev/power user tool

@jthoward64 commented on GitHub (Jun 29, 2021): > Agreed. Sounds like you're worried someone might _choose_ to set their transparency to a setting that your team personally doesn't like. > > This is a feature of every major terminal, and literally no one has a problem with this. Just do a few quick google searches > > * "I can't read my terminal" > * "Terminal text too faint" > * "Terminal too transparent" > > There are none. a little harsh, but nonetheless yeah that's what I was getting at. On the other hand if WT does become the default terminal some kind of accomidation might be a good idea. My commend only applies if WT remains a dev/power user tool

claunia commented

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

@tajetaje My commend only applies if WT remains a dev/power user tool

Really, so no developers requiring assistance need apply? Power users requiring assistance technologies can stay away?

Or are we talking about user-driven adjustments that the producer of the code feeding the terminal display need not be concerned about?

@orcmid commented on GitHub (Jun 29, 2021): > @tajetaje My commend only applies if WT remains a dev/power user tool Really, so no developers requiring assistance need apply? Power users requiring assistance technologies can stay away? Or are we talking about user-driven adjustments that the producer of the code feeding the terminal display need not be concerned about?

claunia commented

@jthoward64 commented on GitHub (Jun 29, 2021):

@tajetaje My commend only applies if WT remains a dev/power user tool

Really, so no developers requiring assistance need apply? Power users requiring assistance technologies can stay away?

Or are we talking about user-driven adjustments that the producer of the code feeding the terminal display need not be concerned about?

No absolutely not, I more mean that I trust developers and power suers to know that turning on a transparency effect where you with have light text on light background is a bad idea AND I trust them to know how to either tune the settings or turn it off. IF terminal does become a part of the Windows OS then the paradigm is different and the WT should and likely will follow other apps and remove some user control in favor of UX.

@jthoward64 commented on GitHub (Jun 29, 2021): > > @tajetaje My commend only applies if WT remains a dev/power user tool > > Really, so no developers requiring assistance need apply? Power users requiring assistance technologies can stay away? > > Or are we talking about user-driven adjustments that the producer of the code feeding the terminal display need not be concerned about? No absolutely not, I more mean that I trust developers and power suers to know that turning on a transparency effect where you with have light text on light background is a bad idea AND I trust them to know how to either tune the settings or turn it off. IF terminal does become a part of the Windows OS then the paradigm is different and the WT should and likely will follow other apps and remove some user control in favor of UX.

claunia commented

@W4RH4WK commented on GitHub (Jun 30, 2021):

Just have sane defaults. Don't have the transparency on by default. If a user enables it, they know where to disable it if it causes problems. I doubt such an option would clutter the UI unnecessarily, but even if that turns out to be a problem, let's just keep transparency as a config option. Power users still have access to it that way. It should be implemented as it is a pretty common feature in terminal emulators.

@W4RH4WK commented on GitHub (Jun 30, 2021): Just have sane defaults. Don't have the transparency on by default. If a user enables it, they know where to disable it if it causes problems. I doubt such an option would _clutter_ the UI unnecessarily, but _even_ if that turns out to be a problem, let's just keep transparency as a config option. Power users still have access to it that way. It should be implemented as it is a pretty common feature in terminal emulators.

claunia commented

@zadjii commented on GitHub (Jun 30, 2021):

Nobody is arguing that this shouldn't be implemented. It will be, when we can implement it in a sane, polished way befitting the default terminal experience in Windows.

Until that time, I'm hoping we can all just remain patient. We want this just as badly as y'all, we're just limited to the engineering constraints common in our industry. We've got a small dev team and a LOT of projects in motion.

@zadjii commented on GitHub (Jun 30, 2021): Nobody is arguing that this shouldn't be implemented. It will be, when we can implement it in a sane, polished way befitting the default terminal experience in Windows. Until that time, I'm hoping we can all just remain patient. We want this just as badly as y'all, we're just limited to the engineering constraints common in our industry. We've got a small dev team and a LOT of projects in motion.

claunia commented

2026-01-30 22:07:32 +00:00

@yumetodo commented on GitHub (Jun 30, 2021):

We should know the difference between "has an ability" and "is default".

@yumetodo commented on GitHub (Jun 30, 2021): We should know the difference between "has an ability" and "is default".

claunia commented

@zerols commented on GitHub (Jul 17, 2021):

like alacritty how to achieve this function？

@zerols commented on GitHub (Jul 17, 2021): like alacritty how to achieve this function？

claunia commented

2026-01-30 22:07:32 +00:00

@zadjii-msft commented on GitHub (Sep 7, 2021):

Ho boy I hate bumping a thread with this many folks on it but I gotta keep my notes somewhere. Just so happens this is the place. No spoilers here this week.

Ship the updated TTH package.
- OH NO IT DOESN'T WORK ON 19H1. Find out why, if it's fixable, or if we just need to have a note.
Fix Mouse wheeling opacity
Figure out if we can get rid of the titlebar in focus mode
do we need WS_EX_LAYERED in AlwaysOnTop mode? Hopefully not, cause that does weird things each settings reload
Re-add the Pane border
Add the SUI background
change opacity to a 0-100 value, with a FloatAsIntPercentConversionTrait
INHERITABLE_SETTING(int, Opacity, UseAcrylic() ? 50 : 100); // Sorry lhecker
But really, make sure that useAcrylic:true (without opacity) defaults to 50%
SUI needs the opacity slicer always visible
update docs

@zadjii-msft commented on GitHub (Sep 7, 2021): Ho boy I hate bumping a thread with this many folks on it but I gotta keep my notes somewhere. Just so happens this is the place. No spoilers here this week. * [x] Ship the updated TTH package. * [ ] OH NO IT DOESN'T WORK ON 19H1. Find out why, if it's fixable, or if we just need to have a note. * [x] Fix Mouse wheeling opacity * [x] Figure out if we can get rid of the titlebar in focus mode * [x] do we need `WS_EX_LAYERED` in `AlwaysOnTop` mode? Hopefully not, cause that does weird things each settings reload * [x] Re-add the Pane border * [x] Add the SUI background * [x] change opacity to a 0-100 value, with a `FloatAsIntPercentConversionTrait` * [x] `INHERITABLE_SETTING(int, Opacity, UseAcrylic() ? 50 : 100); // Sorry lhecker` * [x] But really, make sure that `useAcrylic:true` (without opacity) defaults to 50% * [x] SUI needs the opacity slicer always visible * [ ] update docs

claunia commented

2026-01-30 22:07:32 +00:00

@silverqx commented on GitHub (Sep 20, 2021):

There were so many cries that support from XAML is needed, because XAML doesn't support it, and from the patch is clearly visible that Background="Transparent" was supported a long time and Opacity too.

Anyway, I'm really happy about this PR that is finally available (soon), many thanks to @zadjii-msft for great work. 🔥🚀
I can't wait to start using it daily. 😍

@silverqx commented on GitHub (Sep 20, 2021): There were so many cries that support from XAML is needed, because XAML doesn't support it, and from the patch is clearly visible that `Background="Transparent"` was supported a long time and `Opacity` too. Anyway, I'm really happy about this PR that is finally available (soon), many thanks to @zadjii-msft for great work. 🔥🚀 I can't wait to start using it daily. 😍

claunia commented

@DHowett commented on GitHub (Sep 20, 2021):

from the patch is clearly visible that Background="Transparent" was supported a long time and Opacity too.

You may have missed that we had to use a private API to get this working. Everything looks easy through that lens.

Without us using that API, XAML enforces the presence of a black background under all controls as an "emergency" measure to explicitly prevent transparency.

@DHowett commented on GitHub (Sep 20, 2021): > from the patch is clearly visible that `Background="Transparent"` was supported a long time and `Opacity` too. You may have missed that we had to use a private API to get this working. Everything looks easy through that lens. Without us using that API, XAML enforces the presence of a black background under all controls as an "emergency" measure to *explicitly prevent transparency*.

claunia commented

@silverqx commented on GitHub (Sep 20, 2021):

You may have missed that we had to use a private API to get this working. Everything looks easy through that lens.

I'm pretty sure that this was 1 month work, nothing easy.

Without us using that API, XAML enforces the presence of a black background under all controls as an "emergency" measure to explicitly prevent transparency.

That is absolutely normal that some hacks had to be used, like any other hard PRs, in coding nothing is easy and if you are adding something bigger then you can be pretty sure that you hit some wall and need to use some workarounds.

@silverqx commented on GitHub (Sep 20, 2021): > > You may have missed that we had to use a private API to get this working. Everything looks easy through that lens. I'm pretty sure that this was 1 month work, nothing easy. > > Without us using that API, XAML enforces the presence of a black background under all controls as an "emergency" measure to _explicitly prevent transparency_. That is absolutely normal that some hacks had to be used, like any other hard PRs, in coding nothing is easy and if you are adding something bigger then you can be pretty sure that you hit some wall and need to use some workarounds.

claunia commented

@ghost commented on GitHub (Oct 20, 2021):

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

Handy links:

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

claunia commented

@silverqx commented on GitHub (Oct 20, 2021):

New opacity does not work for me, the background is still blurry, do I need also some .net upgrade? I'm on latest stable windows.

@silverqx commented on GitHub (Oct 20, 2021): New opacity does not work for me, the background is still blurry, do I need also some .net upgrade? I'm on latest stable windows.

claunia commented

@DHowett commented on GitHub (Oct 20, 2021):

"latest stable windows"

What version, specifically?

@DHowett commented on GitHub (Oct 20, 2021): "latest stable windows" What version, specifically?

claunia commented

@silverqx commented on GitHub (Oct 20, 2021):

21H1 19043.1288

@silverqx commented on GitHub (Oct 20, 2021): 21H1 19043.1288

claunia commented

@jthoward64 commented on GitHub (Oct 20, 2021):

New opacity does not work for me, the background is still blurry, do I need also some .net upgrade? I'm on latest stable windows.

21H1 19043.1288

Windows 11 only for now

@jthoward64 commented on GitHub (Oct 20, 2021): > New opacity does not work for me, the background is still blurry, do I need also some .net upgrade? I'm on latest stable windows. > 21H1 19043.1288 Windows 11 only for now

claunia commented

@DHowett commented on GitHub (Oct 20, 2021):

Alas, indeed.

It required some OS changes. We are working to get those backported! 😄

@DHowett commented on GitHub (Oct 20, 2021): ![image](https://user-images.githubusercontent.com/189190/138146483-841dc892-5e84-46be-9012-0f1b76a13b5b.png) Alas, indeed. It required some OS changes. We are working to get those backported! :smile:

claunia commented

@silverqx commented on GitHub (Oct 20, 2021):

On what it depends? ok, thx for the reply, I think it is a great step forward, 1.12 is amazing thx

@silverqx commented on GitHub (Oct 20, 2021): On what it depends? ok, thx for the reply, I think it is a great step forward, 1.12 is amazing thx

claunia commented

@joaoquentalgomes commented on GitHub (Oct 20, 2021):

Any idea when this will be released in a stable version?

@joaoquentalgomes commented on GitHub (Oct 20, 2021): Any idea when this will be released in a stable version?

claunia commented

@DHowett commented on GitHub (Oct 20, 2021):

@quental this will be released in a stable version on our normal "preview -> stable" schedule (so, approximately 6 weeks from now.)

EDIT: assuming that there are no huge issues with it.

@DHowett commented on GitHub (Oct 20, 2021): @quental this will be released in a stable version on our normal "preview -> stable" schedule (so, approximately 6 weeks from now.) EDIT: assuming that there are no huge issues with it.

claunia commented

@jthoward64 commented on GitHub (Oct 20, 2021):

On what it depends? ok, thx for the reply, I think it is a great step forward, 1.12 is amazing thx

see #11180

@jthoward64 commented on GitHub (Oct 20, 2021): > On what it depends? ok, thx for the reply, I think it is a great step forward, 1.12 is amazing thx see #11180

claunia commented

@silverqx commented on GitHub (Oct 20, 2021):

It is not clear on what it depends from that PR, it may be Microsoft.Internal.Windows.Terminal.ThemeHelpers 0.4.210908001, but google is quiet about this package.

@silverqx commented on GitHub (Oct 20, 2021): It is not clear on what it depends from that PR, it may be `Microsoft.Internal.Windows.Terminal.ThemeHelpers 0.4.210908001`, but google is quiet about this package.

claunia commented

@DHowett commented on GitHub (Oct 20, 2021):

There is a XAML feature in Windows 11 that allows us to remove the "emergency black background"[1] from a window.

[1]: xaml has an emergency background because UWP applications aren't supposed to be fully transparent

@DHowett commented on GitHub (Oct 20, 2021): There is a XAML feature in Windows 11 that allows us to remove the "emergency black background"[1] from a window. [1]: xaml has an emergency background because UWP applications _aren't supposed to be fully transparent_

claunia commented

@silverqx commented on GitHub (Oct 20, 2021):

And it will be available through what? new .net version or through new vcredis version, that is what I meant on what it depends, which package or which new version of WHAT will provide the patch. Not technical details how it was implemented 😀

@silverqx commented on GitHub (Oct 20, 2021): And it will be available through what? new .net version or through new vcredis version, that is what I meant on what it depends, which package or which new version of WHAT will provide the patch. Not technical details how it was implemented 😀

claunia commented

@DHowett commented on GitHub (Oct 20, 2021):

It depends on a new version of Windows. It will be distributed through Windows.
If we can get it backported to Windows 10, it will be released through Windows Update.

@DHowett commented on GitHub (Oct 20, 2021): It depends on a new version of Windows. It will be distributed through Windows. If we can get it backported to Windows 10, it will be released through Windows Update.

claunia commented

@silverqx commented on GitHub (Oct 20, 2021):

Ok, thank you, I was only curious, it doesn't matter where is from the patch, somewhere in the windows core maybe 🙂, or somewhere.

@silverqx commented on GitHub (Oct 20, 2021): Ok, thank you, I was only curious, it doesn't matter where is from the patch, somewhere in the windows core maybe 🙂, or somewhere.

claunia commented

@all500234765 commented on GitHub (Oct 26, 2021):

plz keep as up to date! Looking forward to switching to windows terminal, but currently can't because of transparency issues

@all500234765 commented on GitHub (Oct 26, 2021): plz keep as up to date! Looking forward to switching to windows terminal, but currently can't because of transparency issues

claunia commented

@silverqx commented on GitHub (Oct 26, 2021):

I can not wait too for this, I'm super excited about this. 😀 It should be released after 1. december

@silverqx commented on GitHub (Oct 26, 2021): I can not wait too for this, I'm super excited about this. 😀 It should be released after 1. december

claunia commented

@ChrTall commented on GitHub (Nov 8, 2021):

@DHowett Can you tell us how likely it is, that you will be able to backport it?
Is this something you can influence or decided by upstream?
Sadly my 7th gen Intel is not supported by Windows 11 and probably won´t be in the future.

@ChrTall commented on GitHub (Nov 8, 2021): @DHowett Can you tell us how likely it is, that you will be able to backport it? Is this something you can influence or decided by upstream? Sadly my 7th gen Intel is not supported by Windows 11 and probably won´t be in the future.

claunia commented

@zadjii-msft commented on GitHub (Nov 8, 2021):

Can you tell us how likely it is, that you will be able to backport it?

Nope. We're working through it right now. We're putting the weight of our team on it, and we'll give updates whenever we have them. Unfortunately, with the holidays coming up, I'd suspect the OS update pipeline to be a little slower than usual, so bear with us.

@zadjii-msft commented on GitHub (Nov 8, 2021): > Can you tell us how likely it is, that you will be able to backport it? Nope. We're working through it right now. We're putting the weight of our team on it, and we'll give updates whenever we have them. Unfortunately, with the holidays coming up, I'd suspect the OS update pipeline to be a little slower than usual, so bear with us.

claunia commented

@silverqx commented on GitHub (Dec 15, 2021):

Does anybody has it on Win10, it is 8 weeks now and I still don't have this opacity feature on Win10.

@silverqx commented on GitHub (Dec 15, 2021): Does anybody has it on Win10, it is 8 weeks now and I still don't have this opacity feature on Win10.

claunia commented

@jthoward64 commented on GitHub (Dec 15, 2021):

@silverqx See the comment directly above yours. This currently only works in windows 11.

@jthoward64 commented on GitHub (Dec 15, 2021): @silverqx See the comment directly above yours. This currently only works in windows 11.

claunia commented

@silverqx commented on GitHub (Dec 15, 2021):

I know that it works on Win11, but from the previous conversation I understood that it will be backported also to Win10 and it will take ~6 weeks. Am I wrong?

@silverqx commented on GitHub (Dec 15, 2021): I know that it works on Win11, but from the previous conversation I understood that it will be backported also to Win10 and it will take ~6 weeks. Am I wrong?

claunia commented

@jthoward64 commented on GitHub (Dec 15, 2021):

I know that it works on Win11, but from the previous conversation I understood that it will be backported also to Win10 and it will take ~6 weeks. Am I wrong?

I don't think anyone ever said 6 weeks (or even that it was definitely possible). All that has been said publicly is that the terminal team is working with the OS people on it and that they would try and make it happen. Read through some of the team members messages above for more info. If it happens it happens and that is great, but if not oh well.

@jthoward64 commented on GitHub (Dec 15, 2021): > I know that it works on Win11, but from the previous conversation I understood that it will be backported also to Win10 and it will take ~6 weeks. Am I wrong? I don't think anyone ever said 6 weeks (or even that it was definitely possible). All that has been said publicly is that the terminal team is working with the OS people on it and that they would try and make it happen. Read through some of the team members messages above for more info. If it happens it happens and that is great, but if not oh well.

claunia commented

@zadjii-msft commented on GitHub (Dec 15, 2021):

The comment you're referring to is discussing the timeframe for the Preview -> Release channel for the Terminal itself, not the servicing timeframe.

With the holidays, we delayed the Preview->Release promotion anyways (there wasn't too much in the last 6 weeks to justify another release).

Additionally, and totally separately, the internal servicing pipleline hasn't ingested this yet. Servicing the OS takes a while - I honestly don't even know how to guess how long that would take.

We'll be sure to update this thread once there's something to share however!

@zadjii-msft commented on GitHub (Dec 15, 2021): [The comment you're referring to](https://github.com/microsoft/terminal/issues/603#issuecomment-947908313) is discussing the timeframe for the Preview -> Release channel for _the Terminal itself_, not the servicing timeframe. With the holidays, we delayed the Preview->Release promotion anyways (there wasn't too much in the last 6 weeks to justify another release). Additionally, and totally separately, the _internal_ servicing pipleline hasn't ingested this yet. Servicing the OS takes a while - I honestly don't even know how to guess how long that would take. We'll be sure to update this thread once there's something to share however!

claunia commented

@silverqx commented on GitHub (Dec 15, 2021):

It is not a big deal, because I will upgrade to Win11 in the following few months or weeks, thx for replies, I misunderstood it though and you are referring right comment that confused me. 😁 Thx

@silverqx commented on GitHub (Dec 15, 2021): It is not a big deal, because I will upgrade to Win11 in the following few months or weeks, thx for replies, I misunderstood it though and you are referring right comment that confused me. 😁 Thx

claunia commented

@joaoquentalgomes commented on GitHub (Jan 10, 2022):

The comment you're referring to is discussing the timeframe for the Preview -> Release channel for the Terminal itself, not the servicing timeframe.

With the holidays, we delayed the Preview->Release promotion anyways (there wasn't too much in the last 6 weeks to justify another release).

Additionally, and totally separately, the internal servicing pipleline hasn't ingested this yet. Servicing the OS takes a while - I honestly don't even know how to guess how long that would take.

We'll be sure to update this thread once there's something to share however!

Since it was delayed, any idea when this will be released (for win11 ofc)? Thanks!

@joaoquentalgomes commented on GitHub (Jan 10, 2022): > [The comment you're referring to](https://github.com/microsoft/terminal/issues/603#issuecomment-947908313) is discussing the timeframe for the Preview -> Release channel for _the Terminal itself_, not the servicing timeframe. > > With the holidays, we delayed the Preview->Release promotion anyways (there wasn't too much in the last 6 weeks to justify another release). > > Additionally, and totally separately, the _internal_ servicing pipleline hasn't ingested this yet. Servicing the OS takes a while - I honestly don't even know how to guess how long that would take. > > We'll be sure to update this thread once there's something to share however! Since it was delayed, any idea when this will be released (for win11 ofc)? Thanks!

claunia commented

@zadjii-msft commented on GitHub (Jan 12, 2022):

Probably in January some time, but don't hold me to that. Like I said, we don't really want to make a release unless there's actually something to release. There isn't all that much in 1.13 at the moment. We're trying to also line up 1.12 stable with some internal milestones, so I don't think we can actually push 1.12 stable past early Feb.

@zadjii-msft commented on GitHub (Jan 12, 2022): Probably in January some time, but don't hold me to that. Like I said, we don't really want to make a release unless there's actually something to release. There isn't all that much in 1.13 at the moment. We're trying to also line up 1.12 stable with some internal milestones, so I don't think we can actually push 1.12 stable past early Feb.

claunia commented

@joaoquentalgomes commented on GitHub (Jan 12, 2022):

Probably in January some time, but don't hold me to that. Like I said, we don't really want to make a release unless there's actually something to release. There isn't all that much in 1.13 at the moment. We're trying to also line up 1.12 stable with some internal milestones, so I don't think we can actually push 1.12 stable past early Feb.

Thanks for the update! And it's safe to expect this feature in 1.12 stable, right?

@joaoquentalgomes commented on GitHub (Jan 12, 2022): > Probably in January some time, but don't hold me to that. Like I said, we don't really want to make a release unless there's actually something to release. There isn't all that much in 1.13 at the moment. We're trying to also line up 1.12 stable with some internal milestones, so I don't think we can actually push 1.12 stable past early Feb. Thanks for the update! And it's safe to expect this feature in 1.12 stable, right?

claunia commented

@NobleDraconian commented on GitHub (Feb 15, 2022):

@zadjii-msft Will this feature be supported on Windows 10? I just took a look at the preview build that has https://github.com/microsoft/terminal/pull/11180, but it mentions it's only supported on Windows 11.

@NobleDraconian commented on GitHub (Feb 15, 2022): @zadjii-msft Will this feature be supported on Windows 10? I just took a look at the preview build that has https://github.com/microsoft/terminal/pull/11180, but it mentions it's only supported on Windows 11.

claunia commented

@jthoward64 commented on GitHub (Feb 15, 2022):

Can you tell us how likely it is, that you will be able to backport it?

Nope. We're working through it right now. We're putting the weight of our team on it, and we'll give updates whenever we have them. Unfortunately, with the holidays coming up, I'd suspect the OS update pipeline to be a little slower than usual, so bear with us.

@NobleDraconian see above

@jthoward64 commented on GitHub (Feb 15, 2022): > > Can you tell us how likely it is, that you will be able to backport it? > > Nope. We're working through it right now. We're putting the weight of our team on it, and we'll give updates whenever we have them. Unfortunately, with the holidays coming up, I'd suspect the OS update pipeline to be a little slower than usual, so bear with us. @NobleDraconian see above

claunia commented