Sidenote, I'd be perfectly fine if this change also disabled the framerate counter in App.xaml.cpp. It's covering the titlebar so I can't see your change! :) In general, I doubt anyone uses it in their day-to-day and if they have need of it, it can be easily enabled.

Hey Rudy, it looks like this change regresses the position of the text that displays when the docked History/Memory list is empty:

Oops! The worst part is that I saw it when I took screenshots and i thought to myself: "What a weird UI, we should change it"... 🤦‍♂️🤦‍♂️🤦‍♂️ I will update it tonight

Sidenote, I'd be perfectly fine if this change also disabled the framerate counter in App.xaml.cpp. It's covering the titlebar so I can't see your change! :) In general, I doubt anyone uses it in their day-to-day and if they have need of it, it can be easily enabled.

Yours is giant!

But I agree, it's not really something we use daily

I'll be honest, I don't feel like changing the color of the titlebar text makes much of a difference in noticing if the window is focused or not. Acrylic effect is removed from apps when they lose focus, which is much more noticeable. I do like the rest of the changes in this PR.

I agree that we should not change the title bar visuals when the acrylic effect is enabled, but there are a number of scenarios the system will disable acrylic (i.e., Battery Saver or when transparency effects are explicilty disabled by the user in settings). In those cases, we should make sure that we have a visual indication of window focus.

I wasn't suggesting that we should not change the title bar visuals when acrylic effect is enabled. I was only commenting that I personally don't feel that changing the text color from black to gray is that noticeable. If we really need to indicate window focus as a feature requirement (shouldn't Windows handle this for apps?), it seems like we could go futher, for example all text could gray and we could gray the accent color. A visual change like that pops across the whole app instead of just the text in the titlebar. I also realize that this is a much more exhaustive change so I'm not expecting Rudy or anyone else to go implement that. Anyways, I wasn't trying to be contentious. Just voicing one opinion.

As Dave explained, there are a lot of scenarios where acrylic is not available, so we need to have a way to distinguish if the windows are focused or not.

in my opinion, for acrylic and titlebar, we should still modify the title bar color even if acrylic is activated:

• have a consistent UI whether acrylic is enabled or not (in both cases, the unfocused window will look exactly the same)
• match with colors of minimize, maximize, close buttons
• what if the battery saver turns on while Calculator is not focused?
• have a consistent UI with all other applications not using Acrylic
• make it future proof, Acrylic is currently enabled only when a window is focused (for performance reasons), if the OS team decides to change this behavior in a future update, we would be ready.

But, it's also true that a lot of first party applications using Acrylic don't modify the title color when they lose focus (Settings, Maps, Clock, Movie, Photos, Snip...), but they also have the same issue we are trying to fix, so we should probably not use them as a reference.

I let you decide what you prefer, we are very busy this week with @TurtleShip (👋), I can modify the diff tomorrow night with the behavior you prefer.

I wasn't suggesting that we should not change the title bar visuals when acrylic effect is enabled. I was only commenting that I personally don't feel that changing the text color from black to gray is that noticeable. If we really need to indicate window focus as a feature requirement (shouldn't Windows handle this for apps?), it seems like we could go futher, for example all text could gray and we could gray the accent color. A visual change like that pops across the whole app instead of just the text in the titlebar. I also realize that this is a much more exhaustive change so I'm not expecting Rudy or anyone else to go implement that. Anyways, I wasn't trying to be contentious. Just voicing one opinion.

If you gray everything, users will think that actions/buttons are disabled, while they are not, users should still be able to distinct an enabled/disabled button even when the app is not focused. If it was necessary to click 2 times to do an action when the window isn't focused (the first click enabling the window but the event not forwarded to the UI) , I would agree, but (luckily and contrary to some other OSes) it's not how Windows works, even if the app is not focused, a single click on a button will activate the window and generate a click so we should not "gray" them.

If you gray everything, users will think that the actions/buttons are disabled, while they are not, users should still be able to distinct an enabled/disabled button even when the app is not focused.

Great point, let's not have that confusion.

match with colors of minimize, maximize, close buttons

This seems like the best behavior and it's what your PR captures. I checked with a blank UWP app, and the standard titlebar text changes color the same way we do here. The other apps that you called out must have custom titlebars.

I can modify the diff tomorrow night with the behavior you prefer

No need, I think everyone is fine with this change. I did have some feedback to be addressed and then we can get this merged.

Once Microsoft implements the depth shadows with the windowing, that will help make the focused and unfocused Windows more noticeable I think.

Windows already has a larger/darker shadow for active windows. Windows needs more than that though.

Windows already has a larger/darker shadow for active windows. Windows needs more than that though.

I know they have some shadowing there, but I am sure I saw it mentioned at Build, that there are plans to bring in the new depth shadows that have been added into XAML for the actual shell windows.

@rudyhuyn, I have two comments at the top of the thread that I'm still wondering your thoughts on. Looks like there's also merge conflicts that should be fixed up. Almost ready to check this in.

Hey @rudyhuyn, we're ready to merge this change but there's conflicts to resolve.

Hey @rudyhuyn, we're ready to merge this change but there's conflicts to resolve.

thanks for the alert, I will merge tonight!