We need to draw the whole non-client area ourselves

[DHowett-MSFT]

If we want to be able to fully theme the window, we'll probably need to draw the theme parts ourselves. Right now the close button, minimize button and maximize/restore buttons are drawn by DWM/uxtheme if we don't tell it not to.
We don't get much say in where they are displayed (which is why there's a border on the right side of the window), and if we attempt to draw behind them we get an additive blend when the DWM splats the title bar down on top of us.

We probably need to look at DrawThemeBackground, DrawThemeIcon and friends.

[mdtauk]

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

[DHowett-MSFT]

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

[mdtauk]

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

[DHowett-MSFT]

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

[mdtauk]

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

[DHowett-MSFT]

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

[mdtauk]

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  
}  

[makinbacon21]

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.

[DHowett-MSFT]

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

[makinbacon21]

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

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

[Vinny636]

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

[mdtauk]

WinUI 3.0 will possibly solve all these problems

[DHowett-MSFT]

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.

[mdtauk]

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.

[zadjii-msft]

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

[sylveon]

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.

[Stanzilla]

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

[sylveon]

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.

[zadjii-msft]

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]

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.

[DHowett-MSFT]

Yup!

[ghost]

🎉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
• Store Download

[AzAgarampur]

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

[sylveon]

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.

[AzAgarampur]

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.

[DHowett-MSFT]

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.

[AzAgarampur]

Ohh ok I see. I was wondering why GDI code was in TerminalApp. This helps me a lot too for a project, thanks.

On the other hand, how does ApplicationFrameHost.exe do it for UWP apps? Because UWP apps don't have a window, I think they have some sort of IPC to make ApplicationFrameHost do the drawing.

[sylveon]

That prevents using full body acrylic effects unfortunately

…

On Sat, Nov 2, 2019, 20:20 Dustin L. Howett (MSFT) ***@***.***> wrote: 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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#872?email_source=notifications&email_token=ABRELNUUG7W5YMXZLXR442LQRYKOTA5CNFSM4HNRTZCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5H5LY#issuecomment-549093039>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRELNTKOIY5AEP3JCB7DTDQRYKOTANCNFSM4HNRTZCA> .

[DHowett-MSFT]

@sylveon having spent multiple hours in meetings with the people who best understand the win32 stack and the XAML islands stack, I'm going to say that broadly speaking it's not going to be possible to have XI plus non-client drawing plus full acrylic.

Incidentally, the person who contributed the "cut a hole in it" solution was one of the XAML Islands engineers 😉

[sylveon]

Hopefully something that's considered for WinUI 3 😉

…

On Sat, Nov 2, 2019, 20:27 Dustin L. Howett (MSFT) ***@***.***> wrote: @sylveon <https://github.com/sylveon> having spent multiple hours in meetings with the people who best understand the win32 stack and the XAML islands stack, I'm going to say that broadly speaking it's not going to be possible to have XI plus non-client drawing plus full acrylic. Incidentally, the person who contributed the "cut a hole in it" solution was one of the XAML Islands engineers 😉 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#872?email_source=notifications&email_token=ABRELNSM3Y4ZQXUH6CALY5LQRYLGTA5CNFSM4HNRTZCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5H7XQ#issuecomment-549093342>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRELNV6UIDKXSKB72SCC7LQRYLGTANCNFSM4HNRTZCA> .