We need to draw the whole non-client area ourselves #1187

@mdtauk commented on GitHub (May 17, 2019):

I'm guessing a UWP window with an acrylic brush and extended into title bar is not an option?

@mdtauk commented on GitHub (May 17, 2019): I'm guessing a UWP window with an acrylic brush and extended into title bar is not an option?

claunia commented

@DHowett-MSFT commented on GitHub (May 17, 2019):

@mdtauk Alas, if only you knew. We went through a handful of different attempts at UI and toolkit and everything else before we hit upon the one that lets us achieve our goals. Suffice it to say, if we could host a CoreWindow (or anything else built on the Windows "managed window" infrastructure) from a standard "full-trust" application with the ability to launch unconstrained processes, we would have.

What we have isn't complicated and crazy because we're complicated and crazy but because it needs to be.

@DHowett-MSFT commented on GitHub (May 17, 2019): @mdtauk Alas, if only you knew. We went through a handful of different attempts at UI and toolkit and everything else before we hit upon the _one_ that lets us achieve our goals. Suffice it to say, if we could host a CoreWindow (or anything else built on the Windows "managed window" infrastructure) from a standard "full-trust" application with the ability to launch unconstrained processes, we would have. What we have isn't complicated and crazy because _we're_ complicated and crazy but because it needs to be.

claunia commented

@mdtauk commented on GitHub (May 17, 2019):

@mdtauk Alas, if only you knew. We went through a handful of different attempts at UI and toolkit and everything else before we hit upon the one that lets us achieve our goals. Suffice it to say, if we could host a CoreWindow (or anything else built on the Windows "managed window" infrastructure) from a standard "full-trust" application with the ability to launch unconstrained processes, we would have.

What we have isn't complicated and crazy because we're complicated and crazy but because it needs to be.

You should "bang on" at the Windows Team, and get them to slip something into the Win32 framework to enable Acrylic and Opacity in the windows themselves. Maybe a new window type?

You wouldn't be the first team to need to draw their own window frames. Zune, Office, Visual Studio, VS Code, MFC Ribbon, etc.

@mdtauk commented on GitHub (May 17, 2019): > @mdtauk Alas, if only you knew. We went through a handful of different attempts at UI and toolkit and everything else before we hit upon the _one_ that lets us achieve our goals. Suffice it to say, if we could host a CoreWindow (or anything else built on the Windows "managed window" infrastructure) from a standard "full-trust" application with the ability to launch unconstrained processes, we would have. > > What we have isn't complicated and crazy because _we're_ complicated and crazy but because it needs to be. You should "bang on" at the Windows Team, and get them to slip something into the Win32 framework to enable Acrylic and Opacity in the windows themselves. Maybe a new window type? You wouldn't be the first team to need to draw their own window frames. Zune, Office, Visual Studio, VS Code, MFC Ribbon, etc.

claunia commented

@DHowett-MSFT commented on GitHub (May 17, 2019):

Absolutely. We’re chasing a dependency there, but we also want to ship Terminal before the next version of Windows. 😄

@DHowett-MSFT commented on GitHub (May 17, 2019): Absolutely. We’re chasing a dependency there, but we also want to ship Terminal before the next version of Windows. 😄

claunia commented

@mdtauk commented on GitHub (May 17, 2019):

Is there a baseline UI you are hoping to achieve for V1 this summer - which could be upgraded for 19H2 / 20H1 release time?

Is it possible to create a UWP window as a sub-window and use XAML Islands?

I am thinking for the settings window itself as a V1 thing?
[DHowett-MSFT: Moved design image to consolidate design discussion.]

@mdtauk commented on GitHub (May 17, 2019): Is there a baseline UI you are hoping to achieve for V1 this summer - which could be upgraded for 19H2 / 20H1 release time? Is it possible to create a UWP window as a sub-window and use XAML Islands? I am thinking for the settings window itself as a V1 thing? _[DHowett-MSFT: Moved design image to consolidate design discussion.]_

claunia commented

@DHowett-MSFT commented on GitHub (May 17, 2019):

Yes, there is a UI target we are aiming for in 19H1. I’ll leave it to @cinnamon-msft to share the details.

I’ll say that this issue needs to be resolved before we get there ;)

@DHowett-MSFT commented on GitHub (May 17, 2019): Yes, there is a UI target we are aiming for in 19H1. I’ll leave it to @cinnamon-msft to share the details. I’ll say that this issue needs to be resolved before we get there ;)

claunia commented

@mdtauk commented on GitHub (May 17, 2019):

Yes, there is a UI target we are aiming for in 19H1. I’ll leave it to @cinnamon-msft to share the details.

I’ll say that this issue needs to be resolved before we get there ;)

I hope it happens soon. The Taskbar flyouts are able to achieve Acrylic materials, but the way they do it is undocumented.

DwmSetWindowAttribute()

Rafael Rivera made a sample app
https://github.com/riverar/sample-win32-acrylicblur

internal enum AccentState  
{  
    ACCENT_DISABLED = 0,  
    ACCENT_ENABLE_GRADIENT = 1,  
    ACCENT_ENABLE_TRANSPARENTGRADIENT = 2,  
    ACCENT_ENABLE_BLURBEHIND = 3,  
    ACCENT_ENABLE_ACRYLICBLURBEHIND = 4,  
    ACCENT_INVALID_STATE = 5  
}

@mdtauk commented on GitHub (May 17, 2019): > Yes, there is a UI target we are aiming for in 19H1. I’ll leave it to @cinnamon-msft to share the details. > > I’ll say that this issue needs to be resolved before we get there ;) I hope it happens soon. The Taskbar flyouts are able to achieve Acrylic materials, but the way they do it is undocumented. ### DwmSetWindowAttribute() Rafael Rivera made a sample app https://github.com/riverar/sample-win32-acrylicblur ``` internal enum AccentState { ACCENT_DISABLED = 0, ACCENT_ENABLE_GRADIENT = 1, ACCENT_ENABLE_TRANSPARENTGRADIENT = 2, ACCENT_ENABLE_BLURBEHIND = 3, ACCENT_ENABLE_ACRYLICBLURBEHIND = 4, ACCENT_INVALID_STATE = 5 } ```

claunia commented

@makinbacon21 commented on GitHub (May 20, 2019):

I could be totally wrong here, but I was under the impression that Acrylic was one of the UWP APIs MSFT was allowing devs to call inside of a Win32 app--and this seems to be just a Win32 app packaged in the CascadiaApp APPX package. And I believe Win32 apps have full control over their title bars, or most web browsers wouldn't work right. Honestly it might just be better to rewrite the Win32 parts and then package it, rather than saving so much from before. I've learned the hard way that trying to reuse old code, especially old UI elements, often results in many errors when rebuilding for UWP.

@makinbacon21 commented on GitHub (May 20, 2019): I could be totally wrong here, but I was under the impression that Acrylic was one of the UWP APIs MSFT was allowing devs to call inside of a Win32 app--and this seems to be just a Win32 app packaged in the CascadiaApp APPX package. And I believe Win32 apps have full control over their title bars, or most web browsers wouldn't work right. Honestly it might just be better to rewrite the Win32 parts and then package it, rather than saving so much from before. I've learned the hard way that trying to reuse old code, especially old UI elements, often results in many errors when rebuilding for UWP.

claunia commented

@DHowett-MSFT commented on GitHub (May 20, 2019):

@halorocker89 It's not about reusing old code. We literally can't spawn unconstrained processes (like cmd, and powershell, and wsl) in the environment where we can also use the full "UWP" UI toolkit.

@DHowett-MSFT commented on GitHub (May 20, 2019): @halorocker89 It's not about reusing old code. We literally can't spawn unconstrained processes (like cmd, and powershell, and wsl) in the environment where we can also use the full "UWP" UI toolkit.

claunia commented

@makinbacon21 commented on GitHub (May 20, 2019):

@halorocker89 It's not about reusing old code. We literally can't spawn unconstrained processes (like cmd, and powershell, and wsl) in the environment where we can also use the full "UWP" UI toolkit.

Right. Forgot about that. I was recently building something that needed the Ping API, but apparently it's too much of a security violation for the AppContainer, and is therefore not supported. Sad, and tough for y'all, but understandable.

@makinbacon21 commented on GitHub (May 20, 2019): > @halorocker89 It's not about reusing old code. We literally can't spawn unconstrained processes (like cmd, and powershell, and wsl) in the environment where we can also use the full "UWP" UI toolkit. Right. Forgot about that. I was recently building something that needed the Ping API, but apparently it's too much of a security violation for the AppContainer, and is therefore not supported. Sad, and tough for y'all, but understandable.

claunia commented

@makinbacon21 commented on GitHub (May 20, 2019):

Can't you literally just rewrite AcrylicBrush and related stuff? I was pretty sure all that's public (some in blog posts about API updates, some in Docs, some retrievable from the SDK).

@makinbacon21 commented on GitHub (May 20, 2019): Can't you literally just rewrite `AcrylicBrush` and related stuff? I was pretty sure all that's public (some in blog posts about API updates, some in Docs, some retrievable from the SDK).

claunia commented

https://i.imgur.com/EPkcrdt.png

@Vinny636 commented on GitHub (May 21, 2019):

I feel your pain; the universal UI platform can be painful to work with from Win32, especially with the various APIs that are not white-listed [yet]. Just as a word of encouragement, the work you are all doing is awesome!

@Vinny636 commented on GitHub (May 21, 2019): I feel your pain; the universal UI platform can be painful to work with from Win32, especially with the various APIs that are not white-listed [yet]. Just as a word of encouragement, the work you are all doing is _awesome_! https://i.imgur.com/EPkcrdt.png

claunia commented

@mdtauk commented on GitHub (May 21, 2019):

WinUI 3.0 will possibly solve all these problems

@mdtauk commented on GitHub (May 21, 2019): WinUI 3.0 will possibly solve all these problems

claunia commented

@DHowett-MSFT commented on GitHub (May 21, 2019):

At the end of the day, we will still need a window in which to host XAML content (regardless of how it gets on the screen), and therefore we will still need to manage its non-client area, and we will still need to draw the caption buttons ourselves. WinUI 3 is going to be probably the coolest thing to have happened to XAML, but it’s not our nepenthe.

@DHowett-MSFT commented on GitHub (May 21, 2019): At the end of the day, we will _still_ need a window in which to host XAML content (regardless of how it gets on the screen), and therefore we will still need to manage its non-client area, and we will still need to draw the caption buttons ourselves. WinUI 3 is going to be probably the coolest thing to have happened to XAML, but it’s not our nepenthe.

claunia commented

@mdtauk commented on GitHub (May 21, 2019):

At the end of the day, we will still need a window in which to host XAML content (regardless of how it gets on the screen), and therefore we will still need to manage its non-client area, and we will still need to draw the caption buttons ourselves. WinUI 3 is going to be probably the coolest thing to have happened to XAML, but it’s not our nepenthe.

It will be a way to use XAML with full access to Win32's ABIs without the need to host XAML in those Xaml Islands. If there are drawing needs you have, please let the WinUI team know so they can include them.

@mdtauk commented on GitHub (May 21, 2019): > At the end of the day, we will _still_ need a window in which to host XAML content (regardless of how it gets on the screen), and therefore we will still need to manage its non-client area, and we will still need to draw the caption buttons ourselves. WinUI 3 is going to be probably the coolest thing to have happened to XAML, but it’s not our nepenthe. It will be a way to use XAML with full access to Win32's ABIs without the need to host XAML in those Xaml Islands. If there are drawing needs you have, please let the WinUI team know so they can include them.

claunia commented

@zadjii-msft commented on GitHub (Jun 10, 2019):

I'm also gonna take the time to link in #929 here - that PR is the start of a bunch of work in this area

@zadjii-msft commented on GitHub (Jun 10, 2019): I'm also gonna take the time to link in #929 here - that PR is the start of a bunch of work in this area

claunia commented

@sylveon commented on GitHub (Jun 22, 2019):

It's totally possible to support full acrylic on the window if done right.

I had this made quickly when XAML islands where very new, however I haven't figured out how to add native (or native-looking) titlebar controls and a dragable area. It used DwmExtendFrameIntoClientArea and WM_NCCALCSIZE to extend the client area to the whole window, while still having native shadows working correctly.

Sidenote, I really wish SetWindowCompositionAttribute which allows apps today to add an acrylic or blur effect was documented (it's currently not). It's already used in some apps (AMD's Radeon Settings and Terminus are two that come to mind) and would probably allow this app to add acrylic to its frame with minimal effort.

@sylveon commented on GitHub (Jun 22, 2019): It's totally possible to support full acrylic on the window if done right. I had this made quickly when XAML islands where very new, however I haven't figured out how to add native (or native-looking) titlebar controls and a dragable area. It used DwmExtendFrameIntoClientArea and WM_NCCALCSIZE to extend the client area to the whole window, while still having native shadows working correctly. ![image](https://user-images.githubusercontent.com/6440374/59969103-1bcfd280-9514-11e9-902b-8c6e73edc75a.png) Sidenote, I really wish `SetWindowCompositionAttribute` which allows apps today to add an acrylic or blur effect was documented (it's currently not). It's already used in some apps (AMD's Radeon Settings and [Terminus](https://github.com/Eugeny/Terminus) are two that come to mind) and would probably allow this app to add acrylic to its frame with minimal effort.

claunia commented

@Stanzilla commented on GitHub (Jun 22, 2019):

@sylveon does that work without lag? For me Terminus lags hardcore with Acrylic background enabled.

@Stanzilla commented on GitHub (Jun 22, 2019): @sylveon does that work without lag? For me Terminus lags hardcore with Acrylic background enabled.

claunia commented

@sylveon commented on GitHub (Jun 22, 2019):

It doesn't. This one uses AcrylicBrush, which isn't affected by the bug SetWindowCompositionAttribute has. That specific bug has been fixed in recent Insider builds, and could probably also be fixed on stable Windows with a Cumulative Update.

@sylveon commented on GitHub (Jun 22, 2019): It doesn't. This one uses `AcrylicBrush`, which isn't affected by the bug `SetWindowCompositionAttribute` has. That specific bug has been fixed in recent Insider builds, and could probably also be fixed on stable Windows with a Cumulative Update.

claunia commented

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

I haven't figured out how to add native (or native-looking) titlebar controls and a dragable area.

(emp. added)

This is mostly the reason we don't do this, because it turns out it's very hard to do the way we want when combined with XAML Islands.

@zadjii-msft commented on GitHub (Jul 1, 2019): > I haven't figured out how to add native (or native-looking) titlebar controls and **a dragable area**. (emp. added) This is mostly the reason we don't do this, because it turns out it's very hard to do the way we want _when combined with XAML Islands_.

claunia commented

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

Hey @DHowett-MSFT I'm going to mark #1898 as closing this issue, cool? At that point, I think most of the non-client area should be polished enough to count this as done.

@zadjii-msft commented on GitHub (Jul 11, 2019): Hey @DHowett-MSFT I'm going to mark #1898 as closing this issue, cool? At that point, I think most of the non-client area should be polished enough to count this as done.

claunia commented

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

Yup!

@DHowett-MSFT commented on GitHub (Jul 11, 2019): Yup!

claunia commented

@ghost commented on GitHub (Aug 3, 2019):

:tada:This issue was addressed in #1898, which has now been successfully released as Windows Terminal Preview v0.3.2142.0.🎉

Handy links:

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

claunia commented

@AzAgarampur commented on GitHub (Nov 2, 2019):

@sylveon If you don't mind telling me, how were you able to process the hit-test messages in your full XAML island window app? Won't the XAML Window cover the main window?

@AzAgarampur commented on GitHub (Nov 2, 2019): @sylveon If you don't mind telling me, how were you able to process the hit-test messages in your full XAML island window app? Won't the XAML Window cover the main window?

claunia commented

@sylveon commented on GitHub (Nov 2, 2019):

Yeah, normal hit test messages aren't working, I'm still looking for a solution to that. I could add some hitboxes in XAML and go off click events from that, but I'd rather decouple the hosting window and the XAML code.

@sylveon commented on GitHub (Nov 2, 2019): Yeah, normal hit test messages aren't working, I'm still looking for a solution to that. I could add some hitboxes in XAML and go off click events from that, but I'd rather decouple the hosting window and the XAML code.

claunia commented

@AzAgarampur commented on GitHub (Nov 3, 2019):

I have tried extensively to get hit-test messages to pass though XAML island windows to the underlying windows in some of my own apps. Hooking the window procedure of the XAML islands window, or it's input window don't work, and neither does sending WM_SYSCOMMAND.

@AzAgarampur commented on GitHub (Nov 3, 2019): I have tried extensively to get hit-test messages to pass though XAML island windows to the underlying windows in some of my own apps. Hooking the window procedure of the XAML islands window, or it's input window don't work, and neither does sending `WM_SYSCOMMAND.`

claunia commented

@DHowett-MSFT commented on GitHub (Nov 3, 2019):

Terminal ran into both of these issues. The quickest solution for us was to use a GDI region to cut a hole in the island and paint in the hole so it looks seamless. It's really bad, but it lets us work within the platform's limitations.

There may be a slightly better story here with WinUI 3.0.

@DHowett-MSFT commented on GitHub (Nov 3, 2019): Terminal ran into both of these issues. The quickest solution for us was to _use a GDI region to cut a hole in the island_ and paint in the hole so it looks seamless. It's really bad, but it lets us work within the platform's limitations. There may be a slightly better story here with WinUI 3.0.

claunia commented