Feature Request: Standard Opacity options like the traditional console.

NOFUNEVER commented 5 years ago

Perhaps I overlooked it browsing through the json file but i didn't see another means to achieve transparency and i'm not a fan of the acrylic effects blurring factor or the fact that it turns off when the window is not selected. The traditional console provides for a static opacity just like in most nix envs, i'd hope it's just a matter of time before it's implemented here?

DHowett-MSFT commented 5 years ago

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

zadjii-msft commented 5 years ago

See also #593, which has additional info.

silverqx commented 5 years ago

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

TCB13 commented 5 years ago

+1 on this!

zadjii-msft commented 5 years ago

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

TCB13 commented 5 years ago

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

DHowett-MSFT commented 5 years ago

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

TCB13 commented 5 years ago

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

mdtauk commented 5 years ago

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

iCodeSometime commented 5 years ago

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.

lkspencer commented 5 years ago

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.

oneliey commented 5 years ago

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.

silverqx commented 5 years ago

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

ghost commented 4 years ago

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

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

zadjii-msft commented 4 years ago

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.

heaths commented 4 years ago

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

Brassfield commented 4 years ago

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!

fhelwanger commented 4 years ago

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

admered1 commented 4 years ago

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.

silverqx commented 4 years ago

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.

ackvf commented 4 years ago

@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

ilqvya commented 4 years ago

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

Nirmal4G commented 4 years ago

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

zadjii-msft commented 4 years ago

@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

glowtape commented 4 years ago

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

iCodeSometime commented 4 years ago

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.

glowtape commented 4 years ago

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.

zadjii-msft commented 4 years ago

@ future self:

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

Then we'll write some code


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

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

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

Oh no, even with this, we get pre-blurred content
Which leads me to https://github.com/Microsoft/WindowsCompositionSamples/issues/202
Which brings me full circle to the investigation I already did on this last year https://github.com/microsoft/terminal/issues/1753#issuecomment-508070516

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

Varstahl commented 4 years ago

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.

zadjii-msft commented 4 years ago

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.

jthoward64 commented 4 years ago

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.

alxkvx commented 4 years ago

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

zadjii-msft commented 4 years ago

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

alxkvx commented 4 years ago

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

taylus commented 4 years ago

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.

jthoward64 commented 4 years ago

@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

mdtauk commented 4 years ago

@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

zadjii-msft commented 4 years ago

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 😄

AnuthaDev commented 4 years ago

@ future self:

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

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

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

https://github.com/fobrs/Win2DinMFC

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

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

And this post is phenomenal:

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

zadjii-msft commented 4 years ago

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.

AnuthaDev commented 4 years ago

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

zadjii-msft commented 4 years ago

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.

DHowett commented 4 years ago

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?

AnuthaDev commented 4 years ago

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

AnuthaDev commented 4 years ago

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

beviu commented 4 years ago

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

AnuthaDev commented 4 years ago

Okay, its atleast possible for wpf for sure: Screenshot (363)

AnuthaDev commented 4 years ago

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!

jthoward64 commented 4 years ago

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.

AnuthaDev commented 4 years ago

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

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

microsoft / terminal

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