dotMorten commented 3 months ago

Summary

I'm looking at the new TitleBar, and while functionally and visually I LOVE it, I have some concerns about the API itself.

First of all, the naming of Header and Footer is very misleading. Those names typically refer to top/bottom items, and the entire control in-of-itself is a header control. I looked at those properties and couldn't at all guess what they really were for, until I saw this image: Generally I'd prefer naming that allows you do an informed guess what they do, and in the community call several people were confused about this.

So these are left/right, and I'm not actually sure if Header is before or after those buttons (illustration doesn't make that clear). Header also clashes with the Title here, adding extra confusion.

My second (albeit slightly lesser) concern is the use of Pane and Back buttons. It's extremely opinionated, and I worry we're gonna get too many apps looking too identical. I'd rather this was a Button collection of sorts instead, where I could choose to add some buttons, or choose to just put them in the "Headers" content (pending a better name). If I needed a 3rd button there I'm out of luck.

Then there's the TitlebarTemplateSettings class:

I find this a bit weird. When I think template, I think control templates, but this appears to just be a way to set the app icon - why not just set the icon on the TitleBar directly? But more importantly I think that this should be a Window property (not AppWindow, but Window Window!) that also applies if I don't use the TitleBar.

Another approach is perhaps providing a MUCH simpler titlebar control that just takes care of allowing you to interact with buttons and textboxes etc, while still being able to drag the rest, but you own the entire content as a single content item. Then you add a secondary subclass of that titlebar that adds this more opionated version to cover some common scenarios.

lolametro commented 3 months ago

They probably wanted to avoid Left/Right due to RTL languages. Usually it would then be called Begin and End.

riverar commented 3 months ago

Agree with the commentary above. To add:

Header and Footer are very confusing. One proposal is to align with Microsoft Fluent components, which use [Content]Before and [Content]After (https://react.fluentui.dev/?path=/docs/components-input--default#content-before-after). This terminology is also suitable for right-to-left languages.

It's also confusing this isn't just part of Window, so that things like setting the icon are naturally wired up to WM_SETICON.

dotMorten commented 3 months ago

Yeah being able to write

<Window>
    <Window.TitleBar>
         <TitleBar />
    </Window.TitleBar>
</Window>

would have been way more intuitive, but unfortunately the baseclass of Window is wrong and prevents this.

MikeHillberg commented 3 months ago

That property element syntax is OK on Window; that's a general Xaml language syntax and not specific to DO. E.g. you can do

<Window>
    <Window.Title>
        My Window Title
    </Window.Title>
</Window>

dotMorten commented 3 months ago

@MikeHillberg Yes but now you can't evaluate binding context. The thing falls apart a soon as you want to bind etc:

<Window>
    <Window.TitleBar>
         <TitleBar Subtitle="{Binding CurrentOpenFile}" />
    </Window.TitleBar>
</Window>

Not to mention your example above didn't even work until very recently and had to be set in code-behind ;D

mdtauk commented 3 months ago

What would be the best practice to use this TitleBar control, along with a TabView control, where the tabs are not a drag region, but the bar where the tabs are contained, is draggable?

Titlebar's Tall mode would fit well with the TabView, but can you collapse the Header, Icon, Title, Subtitle parts, so content takes up more space?

moshegutman commented 3 months ago

Leading/Trailing instead of Header/Footer would work for RTL too.

That's what Apple does: https://developer.apple.com/documentation/swiftui/toolbaritemplacement/topbarleading

BreeceW commented 3 months ago

My second concern is the use of Pane and Back buttons. It's extremely opinionated, and I worry we're gonna get too many apps looking too identical. I'd rather this was a Button collection of sorts instead, where I could choose to add some buttons, or choose to just put them in the "Headers" content (pending a better name). If I needed a 3rd button there I'm out of luck.

I agree that the pane button is too opinionated and having a button collection instead would be good, but the back button makes sense as a dedicated option. Uniformity there is good and provides a direct alternative to the old CoreWindow back button from UWP. The back button also has a different style that makes sense only for the back button (goes all the way to the edges, like caption buttons), so it’s good that it’s distinct.

roxk commented 3 months ago

It's extremely opinionated, and I worry we're gonna get too many apps looking too identical.

It being opinionated is a good thing. Windows has been blamed for its inconsistency for a long time and enforcing some kind of consistency is good here. Devs who wish to have custom button collections could always implement their own. I find it wise to leave the official default to represent "what we want devs to do". That's the point of the title bar control - to make apps look the same according to the fluent guideline.

(In fact, you can argue navigation view etc also suffer from this "all apps look the same" problem, but again this is a good thing to have uniformity/consistency. The biggest benefit of consistency is users familiarity)

AndrewKeepCoding commented 3 months ago

First of all, the naming of Header and Footer is very misleading.

At least, it's consistent with the NavigationView's TopPane.

dotMorten commented 3 months ago

At least, it's consistent with the NavigationView's TopPane.

I'd argue that's just as confusing. I can see the consistency argument to some extent, but we could also break with it before it becomes a pattern.

AndrewKeepCoding commented 3 months ago

I'd argue that's just as confusing. I can see the consistency argument to some extent, but we could also break with it before it becomes a pattern.

I see. It's still in experimental preview. Everything is possible. Then I hope it gets simpler as you suggest in your comment above.

dotMorten commented 3 months ago

It's still in experimental preview. Everything is possible

Yeah hopefully the design isn't settled yet. I assume the experimental previews are here for not just bug testing, but also so we have a chance to give feedback on the overall features, hence this issue.

mdtauk commented 3 months ago

It's still in experimental preview. Everything is possible

Yeah hopefully the design isn't settled yet. I assume the experimental previews are here for not just bug testing, but also so we have a chance to give feedback on the overall features, hence this issue.

I think this control is trying to match the Design guidance the WinUI team put in the Figma toolkit some time ago - and match what the product teams have been doing with their custom Title Bars.

The only pre-existing use case that comes to mind is having a TabView in the titlebar region.

Maybe a button collection would enable something like OneNote

Things like Visual Studio Code are already possible with the TitleBar control as is

ghost1372 commented 3 months ago

I am comfortable with the current design, however renaming the header and footer will be better, but I disagree with simplifying the title bar and removing the pane button, if you want to put more buttons you can use Header property. or if you dont need pane button, just Hide it. (IsPaneToggleButtonVisible). There is nothing wrong with the programs being similar. Do not forget that the title bar is an optional control and is not mandatory. If you need more or simpler items, you can create your own title bar. or If you need various changes, maybe using Labs is more useful for you.

Tiktack commented 3 months ago

My second concern is the use of Pane and Back buttons. It's extremely opinionated, and I worry we're gonna get too many apps looking too identical.

I think opposite, that this is very good when platform get consistency across apps. This the first concern about windows, that every app looks different some from XP era, some from Vista/7, some Win10.

When you have a common component that satisfies 95% applications and it looks identical - this is good. It helps with muscle memory and overall experience.

eduardobragaxz commented 3 months ago

I disagree about the Pane and Back buttons point as well. I like that they're options in there.

shinta0806 commented 3 months ago

I have a request for the Title / Subtitle property.

The Subtitle property is not required. Instead, I would like the Title property to be a UIElement instead of a String, so that I can put in a Stackpanel, etc.

This will keep the properties clean, and if you want to include Subtitle, just put Title and Subtitle in the StackPanel.

eduardobragaxz commented 3 months ago

Isn't that the Header?

Jay-o-Way commented 3 months ago

@shinta0806

off-topic
put your Stackpanel in the Content

shinta0806 commented 3 months ago

1. off-topic

Sorry, I meant TitleBar API feedback, but if you mean off-topic, forget it.

dotMorten commented 3 months ago

Just realizing that the repo https://github.com/microsoft/microsoft-ui-xaml-specs is still a tiny bit alive. Perhaps the TitleBar API should have been proposed over there first and feedback solicited prior to shipping it in EXP1? There's been several new controls shipped in the past few releases, but none of them went through the spec repo.

dongle-the-gadget commented 3 months ago

For whatever reason, the Content and Footer regions are both dragging regions rather than interactive regions for my code. Is there anything wrong with this?

<TitleBar x:Name="TitleBarControl" IsBackButtonVisible="True" IsPaneToggleButtonVisible="True" Title="Sample App" Subtitle="Sample">
    <AutoSuggestBox QueryIcon="Find" PlaceholderText="Find" MinWidth="300" MaxWidth="500" Margin="8"/>
    <TitleBar.Footer>
        <PersonPicture Height="30" Width="30" Initials="JD" />
    </TitleBar.Footer>
</TitleBar>

public MainWindow()
{
    this.InitializeComponent();
    this.ExtendsContentIntoTitleBar = true;
    this.AppWindow.TitleBar.PreferredHeightOption = Microsoft.UI.Windowing.TitleBarHeightOption.Tall;
    this.SetTitleBar(TitleBarControl);

    TitleBarControl.Loaded += TitleBarControl_Loaded;
}

private void TitleBarControl_Loaded(object sender, RoutedEventArgs e)
{
    // Parts get delay loaded. If you have the parts, make them visible.
    VisualStateManager.GoToState(TitleBarControl, "SubtitleTextVisible", false);
    VisualStateManager.GoToState(TitleBarControl, "ContentVisible", false);
    VisualStateManager.GoToState(TitleBarControl, "FooterVisible", false);

    // Run layout so we re-calculate the drag regions.
    TitleBarControl.InvalidateMeasure();
}

AndrewKeepCoding commented 3 months ago

@dongle-the-gadget Don't worry. You are not the only one.

9702