Proposal Add TitleBar

[insinfo]

• Overview The title bar is a bar located at the top of a view/window/page/activity or at the top of a Dialog that displays the name of the view or the name of the app being used. In addition to providing an open app or view description, the title bar May also contain other useful features that depend on the app, such as Close, maximize, minimize, resize, scroll, app icon among other features.

• Scenario The idea here is to give the developer more freedom and more control over all visual aspects of the App, and standardize the title bar as a UI control within the view.

• Example in XAML.

  <Window>
  <TitleBar  Title="Title" Icon="icon.png" .../>   
  </Window>

    Or

<Window>
    <TitleBar>
        <Content>
            <TextBlock Text="Title"/>
            <Button Content="X"/>
            <ImageButton Source="maximize.svg"/>
            <Image Source="appIcon.svg"/>
        </Content>
    </TitleBar >
</Window>

• Links https://www.syncfusion.com/kb/4585/how-to-customize-the-titlebar-of-the-chromelesswindow https://stackoverflow.com/questions/24654845/c-sharp-wpf-custom-title-bar-drag-window-from-top-when-maximized-doesnt-wo
• Imagens

[birbilis]

the classic statusbar allowed to have multiple panes in it so probably would be similar. However since this also seems to host a hamburger menu etc., it's more of a panel. Thinking in PME model (Property/Method/Event), what special does it have above of a panel API? Just the Title property and probably a Content array (multiple children)?

[drew-hoffman]

@birbilis consistency. A panel can be defined in any way while a titlebar is a specific implementation with a consistent UI. A consistent UI leads to a better UX.

[mdtauk]

TitleBar seems an inadequate name for the functionality, and on Windows can cause confusion with the Window TitleBar with the Min, Max, Close buttons.

HeaderBar perhaps?

[drew-hoffman]

I would argue that it should be part of the titlebar. Edge puts tabs in the title bar, and on phone OSs, there are no min/max/close buttons. I think you'd have to think about the implementation carefully, but there's no reason to have separate controls (is there?)

[crutkas]

I'm agreeing with @mdtauk with confusion.

can we get some of the needed items:

• Add a brief overview of what you are proposing and why it belongs in XAML Standard (in keeping with the principles of the effort).
• Provide a clear usecase/scenario that describes how this API benefits in sharing cross-platform UI code, preferably a scenario from your experience or application that clearly illustrates why a control/API would benefit from being standardized.
• Add a brief example in XAML syntax for your proposal.
• Provide links to issues/discussions where this proposal has been talked about as well as any other pointer to where this originated or got discussed that could describe the motivation.

[birbilis]

as I said already I think, the screenshots show several different usages, doesn't look like a simple titlebar, so just a Text property isn't enough obviously

[crutkas]

I'm just calling it out, right now this is pretty vague based on screen shots :)

[riquenunes]

I think it's not a bad idea, but the name would be definitely confusing on a desktop environment.

Maybe it could be based on NativeScript's ActionBar?

[birbilis]

aren't all those ToolBars anyway? ActionBar does sound more modern in name, but ToolBar is classic one

interesting quote from NativeScript ActionBar url:

The ActionBar is the NativeScript common abstraction over the Android ActionBar and iOS NavigationBar.

[weitzhandler]

I'd like the title bar to be a single content control. Which can be text, buttons or any templated control.

@greenwizard88

consistency. A panel can be defined in any way while a titlebar is a specific implementation with a consistent UI. A consistent UI leads to a better UX.

I disagree, consistent UIs should be recommended, not enforced.

[insinfo]

The title bar is a bar located at the top of a view or at the top of a Dialog that displays the name of the view or the name of the app being used. In addition to providing an open app or view description, the title bar May also contain other useful features that depend on the app, such as Close, maximize, minimize, resize, scroll, app icon among other features.

[birbilis]

Emulating platform's window-buttons functionality (close/minimize/maximize-restore/full-screen) would be helpful indeed (in the sense that the app author won't have to implement the respective functionality themselves).

I mean via some native-looking templates, not sure if you can use native controls here in all platforms, usually hiding of the window chrome is possible and adding your own. Doing other stuff like repositioning say native maximize button is more lowlevel and may not be allowed.

[mdtauk]

With UWP on Windows, the developer can not replace the standard window controls. These are rendered above the content, but you can change the colours of it, and render elements behind them.

This kind of control is achievable with an Application Bar, but there may be some merit in encapsulating an AppBar/CommandBar inside a control, if the use case and purpose for it can be clearly defined, and there is a proven benefit for developers in folding it all into a custom control

[insinfo]

@mdtauk This is possible in Android, IOS, WPF, Windows Forms...

[mdtauk]

@insinfo iOS has no windowing mode, only split screen, so no window controls to implement. I don't know enough about Android's windowing mode. WPF and Windows Forms are not part of XAML Standard. TitleBar

Application Bar used as a "HeaderBar" control, with allowance for the NavigationView button

The bottom image is kind of what you are asking for. An ApplicationBar at the top, with the NavigationView button, a page heading, and the standard ApplicationBarButtons and SecondaryButtons Flyout, but combined into a single control.

Template10 has a similar control it calls PageHeader - https://github.com/Windows-XAML/Template10/wiki/Controls#pageheader

[insinfo]

@mdtauk You did not understand what I meant. What I said was that in WPF and Windows Forms, you can disable window decoration, in IOS and Android, you get a similar effect when creating a full screen application. Then just implement a custom control with the exit buttons and etc.

[crutkas]

@insinfo please provide the additional information and try for much more crisp asks. Titlebar and removing window chrome are different asks.

[birbilis]

Actually, in UWP too you can have fullscreen app, so that could be considered a usecase too. Probably in some future version they'll allow hiding the window chrome too if they don't now

Speaking of fullscreen, I find it strange that most Win8 Store apps had a maximize button on their window bar, but many (or most?) Win10/UWP ones don't (one was even showing it instead of the maximize button). Would be nice if there was a consistent cross-platform way to define such things (e.g. if you show a fullscreen button or not and define event handler for the transition to it) in your UI declaratively (probably you can do such things imperatively now). That would either go to properties of your main window (or properties of some titlebar child control that you host in it). Could else go to some application configuration file (manifest), but since you can't define event handlers in that, best would be via the titlebar or directly via its parent window/form

[insinfo]

@crutkas I upgraded according to the new Issue standard. I think the TitleBar idea has now been well defined.

@birbilis I am open to suggestions, feel free to suggest