Labs-Windows
Labs-Windows copied to clipboard
[Experiment] TitleBar
Addressing: https://github.com/CommunityToolkit/Labs-Windows/discussions/454
Tnx @niels9001
ContextMenu theme is wrong and always light (i can fix this issue, can i make a pr for this?)
this code can fix this issues:
public static void SetPreferredAppMode(ElementTheme theme)
{
if (theme == ElementTheme.Dark)
{
NativeMethods.SetPreferredAppMode(NativeMethods.PreferredAppMode.ForceDark);
}
else if (theme == ElementTheme.Light)
{
NativeMethods.SetPreferredAppMode(NativeMethods.PreferredAppMode.ForceLight);
}
else
{
NativeMethods.SetPreferredAppMode(NativeMethods.PreferredAppMode.Default);
}
NativeMethods.FlushMenuThemes();
}
@niels9001 For some of the problems I reported, I can create a PR. Is that possible?
Tnx @niels9001
Some Issues:
- TitleBar Buttons Should be updated based on windows theme in Active/DeActive State: (i can fix this issue, can i make a pr for this?)
Sure, go ahead - feel free to PR against this branch!
- ContextMenu theme is wrong and always light (i can fix this issue, can i make a pr for this?)
I believe WASDK 1.4 should I address this issue.. let me sync with that team to see if that's correct and we don't need to do any registry stuff?
i pushed a commit here https://github.com/ghost1372/Labs-Windows/commits/UpdateCaptionButtons
I don't know if it is possible to merge another PR on this PR? Anyway, I submited a PR here https://github.com/CommunityToolkit/Labs-Windows/pull/460
ContextMenu theme is wrong and always light (i can fix this issue, can i make a pr for this?)
IIRC it requires a private API to be used extremely early into the loading process.
in TitleBar Height = Standard , we can not use VerticalAlignment="Center" for AutoSuggestBox or other controls
That's the reason "tall" should be used as soon as there are interactive/input controls. Don't know if it's possible to force this setting, in the logic, based on content?
in TitleBar Height = Standard , we can not use VerticalAlignment="Center" for AutoSuggestBox or other controls
That's the reason "tall" should be used as soon as there are interactive/input controls. Don't know if it's possible to force this setting, in the logic, based on content?
Microsoft itself has used the standard mode, so we definitely do not need the tall mode to implement this mode, Store is a perfect example
@niels9001 When will you merge this PR? It's been almost 2 weeks...
@ghost1372 you might want to re-count those pixels
you might want to re-count those pixels
I don't want the size of the buttons to be big, just like the store, I want it to be small, but the autosuggestbox stays in the center!
@ghost1372 oh sorry, now i see those buttons. @niels9001 those should stay untouched.
@Jay-o-Way Please leave any generic questions/comments in the discussion and not in this PR.
in TitleBar Height = Standard , we can not use VerticalAlignment="Center" for AutoSuggestBox or other controls
That's the reason "tall" should be used as soon as there are interactive/input controls. Don't know if it's possible to force this setting, in the logic, based on content?
Microsoft itself has used the standard mode, so we definitely do not need the tall mode to implement this mode, Store is a perfect example
@niels9001 When will you merge this PR? It's been almost 2 weeks...
I have some other stuff that got prioritized. I think in terms of features, we are in a good spot with this PR - or do you see any must-have things that need to be fixed still? I think having some basic tests in place would be good to have - if that's something you want to help out with let me know!
@niels9001 oh i got it, In general, everything is good,
There are just a few minor issues:
AutoConfigureCustomTitleBar="False"
It causes a null exception
VerticalAlignment="Center"
for AutoSuggestBox or other controlsThe title bar is very slow to apply and I can practically see the default title bar!
I have an app that has used a customized title bar (codes from MS documentation) and it is very fast and nothing is visible, but TitleBar Control is slow!
~~I think that’s just a current limitation of WinUI 3. The Store App is UWP so it’s merely extending the view into the title bar instead of having to hide the title bar then load the control in WinUI 3.~~
Is that a UWP app in your example?
I think that’s just a current limitation of WinUI 3. The Store App is UWP so it’s merely extending the view into the title bar instead of having to hide the title bar then load the control in WinUI 3.
See my second screenshot, it's a WinUI app, everything is normal!
@TyJOrtiz no its a winui 3 app
I think that’s just a current limitation of WinUI 3. The Store App is UWP so it’s merely extending the view into the title bar instead of having to hide the title bar then load the control in WinUI 3.
See my second screenshot, it's a WinUI app, everything is normal!
@TyJOrtiz no its a winui 3 app
Ideally, the ExtendContentIntoTitleBar
is set to true in App.xaml.cs
- that's when you don't see it changing.
Doing that within the control does not seem to be esrly enough. Would it make sense to add this as guidance in the sample/doc? Or any other thoughts on how we could set this earlier?
Doing that within the control does not seem to be esrly enough. Would it make sense to add this as guidance in the sample/doc? Or any other thoughts on how we could set this earlier?
I do not have enough experience, I am currently investigating This issue is mentioned in the Microsoft documentation
Set ExtendsContentIntoTitleBar to true in the MainWindow constructor. If you set it in code that gets called later, the default system title bar might be shown first, and then hidden.
@niels9001 I tested different ways and finally I came to a conclusion.
Unfortunately, I did not find a place to solve this issue in the title bar codes.
But we can solve this issue in the OnLaunched
method
The important thing is that we must write these codes after Window is Created, moving the code before or after currentWindow.Activate();
has no effect
if we use currentWindow.AppWindow.TitleBar.ExtendsContentIntoTitleBar
this is result:
protected override void OnLaunched(Microsoft.UI.Xaml.LaunchActivatedEventArgs e)
{
currentWindow = new Window();
currentWindow.AppWindow.TitleBar.ExtendsContentIntoTitleBar = true;
currentWindow.AppWindow.TitleBar.ButtonBackgroundColor = Colors.Transparent;
It would be great if we could create the window in the public App()
method, but unfortunately, the window is not created and always is null
public App()
{
this.InitializeComponent();
currentWindow = new Window(); // always is null
}
If this issue can be solved by the titlebar codes, it will be great, otherwise, this issue/solution should be mentioned in the documentation.
Founded Bugs:
Bug | Fixed | Solution | Remark |
---|---|---|---|
The title bar is very slow to apply and I can practically see the default title bar! | ❌ | write these codes after Window is Created: currentWindow.AppWindow.TitleBar.ExtendsContentIntoTitleBar = true; currentWindow.AppWindow.TitleBar.ButtonBackgroundColor = Colors.Transparent; |
Commit |
VerticalAlignment="Center" for AutoSuggestBox or other controls |
❌ | we can override TitleBarCompactHeight <x:Double x:Key="TitleBarCompactHeight">48</x:Double> |
- |
in RTL layout Title, Icon and other buttons are spaced as far as the CaptionButtons (The first run everything is fine, when changing the size of the window, the controls are spaced out) | ❗ | This issue is related to Windows App SDK and reported here | |
-- |
Thank you @niels9001 4 of the issues are fixed, but 2 of them remain
Thank you @niels9001 4 of the issues are fixed, but 2 of them remain
Thanks for the great overview!!! Hopefully WASDK 1.4 resolves the RTL issue! Do you have any idea what is causing the menu button glitch? Almost feels like the dragregion is blocking it somehow?
Thank you @niels9001 4 of the issues are fixed, but 2 of them remain
Thanks for the great overview!!! Hopefully WASDK 1.4 resolves the RTL issue! Do you have any idea what is causing the menu button glitch? Almost feels like the dragregion is blocking it somehow?
The issue occurs when the back button is shown or hidden, so when the back button changes state the drag region must be updated.
@niels9001
i found another bug!
we can not move window or exit full screen (drag & drop or double click on Titlebar) if we use Win + Right or Left
--
and this is MS Store which is working fine!
It seems that SetDragRects is marked as deprecated in the metadata and there is a new API in v1.4,
Microsoft.UI.Input.InputNonClientPointerSource.GetForWindowId(wndId).SetRegionRects(NonClientRegionKind, Rects)
InputNonClientPointerSource in the Microsoft.UI.Input namespace can be used for custom titlebar scenarios to define non-client area regions. Code can register for corresponding events like hover and click events on these regions.
https://github.com/microsoft/microsoft-ui-xaml/issues/8901 https://learn.microsoft.com/windows/windows-app-sdk/api/winrt/microsoft.ui.input.inputnonclientpointersource?view=windows-app-sdk-1.4
microsoft/microsoft-ui-xaml#8901 https://learn.microsoft.com/windows/windows-app-sdk/api/winrt/microsoft.ui.input.inputnonclientpointersource?view=windows-app-sdk-1.4
I see you quoted my question and I think you should take a look at this: https://learn.microsoft.com/en-us/answers/questions/1362230/how-to-fix-appwindow-titlebar-setdragrectangles-no?comment=answer-1315251&page=1#comment-1370034 Now I'm confused, I don't know why others don't have problems, but I have problems... Can you help me?
I don't have any answer. Just thought I would share something related. All I know is that version 1.4 is very new, so I imagine many developers will struggle with the same thing. Eventually it's up to @niels9001, he has his connections. 👍🏻
I don't have any answer. Just thought I would share something related. All I know is that version 1.4 is very new, so I imagine many developers will struggle with the same thing. Eventually it's up to @niels9001, he has his connections. 👍🏻
Well, I'll look for the answer first.
oh finally there is a sample code: https://github.com/microsoft/WinUI-Gallery/pull/1360
oh finally there is a sample code: microsoft/WinUI-Gallery#1360
Oh, this is great! Should make things easier in for the WASDK code. WASDK 1.4 is required though, the Toolkit is still on 1.3.
oh finally there is a sample code: microsoft/WinUI-Gallery#1360
👋🏾 this PR is merged now and yes, it requires the use of new InputNonClient apis which are only available on winappsdk 1.4 onwards