search

microsoft / microsoft-ui-xaml

Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications
MIT License
6.36k stars 678 forks source link

Proposal: Add a TabControl (same as WPF) #4555

Open robloo opened 3 years ago

robloo commented 3 years ago

The TabContol can be superceded by the more modern TabGroup in #5223. This issue will be closed if TabGroup is accepted.

Proposal: Add a TabControl (same as WPF)

This issue came from the discussions around removal of the Pivot. I've assembled the options below of which this is number 2.

  1. Rewrite the Pivot fixing the issues and updating the design
  2. #4555 Bring back the TabControl from WPF (better data binding and simpler use with both header+content together)
  3. Rework TabView and make it usable for all cases instead of only for top-level document style navigation (Can't fix the binding inconveniences though and there are some hardcoded things that will be tricky to change at this point)

  4. 2310 Adopt more powerful concepts like SwitchPresenter + Radio/ToggleButtonGroup header (More powerful but not as rapid/user-friendly to develop with).

Summary

A TabControl is an entirely self-contained 'container' for general-purpose content. It is intended for static tabs (that cannot be closed or reordered in the UI) It is useful to place anywhere in an app whether that be a side-pane or other small subset of the UI. It is not overdesigned to function for only top-level navigation such as NavigationView or TabView.

A TabControl is composed of individual TabItems. Each TabItem can specify general-purpose Content and Header information and then be added to the TabControl. Really, just following WPF with a few upgrades while re-implementing would be all that is needed.

A fluent-UI theme of the TabControl would likely look exactly like the pivot.

Lot's of examples for a tab-like scenario are given starting here: https://github.com/microsoft/microsoft-ui-xaml/issues/4492#issuecomment-797829284 and also here: https://github.com/microsoft/microsoft-ui-xaml/issues/2310#issuecomment-801259653

exaaaaaa

Rationale

There has never been a good, general-purpose TabControl added to UWP. Historically, the Pivot has been used for these scenarios but has fallen out of favor and is now dropped from WinUI 3. The recommended alternatives including NavigationView and TabView are not adequate replacements for TabControl or Pivot:

Also see:

Scope

There are a few things that can be upgraded but what WPF provided is more than good enough to start:

Capability Priority
TabControl Must
TabItem Must
Ability to hide tabs Must
Tabs support both header and content Must
Tabs may size to header content or be uniform width Should
Tab re-arranging Could
Tab closing None

Important Notes

This is different from the 'ButtonGroup' or 'SegmentedControl' concept discussed here. The ButtonGroup is just a strip of header-like information and does not manage showing/hiding of content.

Open Questions

michael-hawker commented 3 years ago

Our original intent with TabView in the toolkit was to be a superset of TabControl from WPF, I originally did some comparison tests. The main thing missing was the orientation property which still hasn't been implemented on the WinUI one. The additional aspect was some of the header buttons part.

I don't know if it makes sense to have both a TabControl and a TabView when they'd basically just be different styles or slightly different behaviors that could be properties.

robloo commented 3 years ago

Our original intent with TabView in the toolkit was to be a superset of TabControl from WPF, I originally did some comparison tests.

When the WinUI team implemented the control they had a different objective I believe. It isn't really a superset and the control was designed specifically for document tabs as a top-level navigation experience. The design and interaction was implemented accordingly (and is now overdesigned restricting more general cases). The documentation actively discourages other use cases as well.

Good point though and I'll probably go back and have the community toolkit implementation resurrected internally. Since it's already in C# it will be very quick to get it restyled and ready to go as a Pivot replacement.

I don't know if it makes sense to have both a TabControl and a TabView when they'd basically just be different styles or slightly different behaviors that could be properties.

You're right and it doesn't make sense to have two similarly named controls. However, the TabView has gone down a different path right now. If WinUI creates an alternative style and supports disabling a lot of the dynamic functionality it could be usable as a Pivot/TabControl replacement. As stated here "If they want to rework the control and make it better for other scenarios -- great."

If Microsoft shows any willingness at all to redo some of the TabView functionality and develop an alternative style I'll gladly repurpose this issue into a modification of TabView instead of a new TabControl to fill the Pivot role in this area.

mdtauk commented 3 years ago

ViewSwitcher may be a better name to avoid confusion with the TabView control

huoyaoyuan commented 3 years ago

I don't know if it makes sense to have both a TabControl and a TabView when they'd basically just be different styles or slightly different behaviors that could be properties.

For different API shapes. The WPF TabControl's API is very friendly for data binding. The WinUI TabControl requires a lot of code behind to work. The biggest mistake is not associating tab content with each tab item.

robloo commented 3 years ago

ViewSwitcher may be a better name to avoid confusion with the TabView control

Note another concept called SwitchPresenter in the community toolkit. This has no header but can be used to cycle through views. It would align with your concept of separate controls for header and content/view switching.

I don't know if it makes sense to have both a TabControl and a TabView when they'd basically just be different styles or slightly different behaviors that could be properties.

For different API shapes. The WPF TabControl's API is very friendly for data binding. The WinUI TabControl requires a lot of code behind to work. The biggest mistake is not associating tab content with each tab item.

Another excellent point. I haven't considered the lack of binding support in WinUI controls recently but it's a serious problem that crept in to several of the controls over the years. Lack of good data binding support alone does justify a new control.

Noemata commented 3 years ago

@robloo , I appreciate your premise for replacing Pivot, but Microsoft's posture regarding Pivot is disingenuous. I've never used the Pivot control as is. In every use case I use a specific style to get the UI to where I want it. This is one of the hallmarks of XAML, styles allow you to radically reshape a given control, irrespective of its original design criteria. The posture that Microsoft has chosen, that maintaining or reshaping Pivot is somehow a resource drain belies one of the more awesome capabilities of XAML. I know some of the UI stylists at Microsoft. They could crank out a dozen variations of a Pivot style in under a day. So please, Microsoft, stop with the rationalizations that wind up looking foolish.

It's plainly obvious supporting the the use cases of Pivot were not in consideration here. There is no logic to support Microsoft's proposed rationale for removing Pivot given we reached Preview 4 before Microsoft decided to drop it. What's the real reason? Only the fly on the wall knows.

How many more like decisions will the community suffer through?

robloo commented 3 years ago

@Noemata This issue is also to clearly point out to Microsoft that there is a feature gap without the Pivot. Of course I hope they change course regarding Pivot and rework what we already have. To get TabControl-like functionality back the easiest would be to rewrite/rework the pivot. TabView modification may be more problematic as discussed above.

Microsoft seems to need issues to track feedback. Without this issue I can easily see Microsoft dismissing the lack of TabControl-like functionality with the removal of Pivot.

shaheedmalik commented 3 years ago

It needs to support touch with the ability to swipe to change sections.

Noemata commented 3 years ago

@robloo , understood. I just think it's a waste of energy to focus on Pivot at this stage. It's an easy control to duplicate. I wasn't concerned about Pivot specifically, but the posture Microsoft has adopted. There are bigger fish to fry.

Compromising on Pivot was a super easy win for Microsoft. Oh well. C'est la vie.

(A good start: https://github.com/unoplatform/uno/blob/master/src/Uno.UI/UI/Xaml/Controls/Pivot/Pivot.cs)

robloo commented 3 years ago

@mdtauk echoed the sentiment about possible naming confusion with two 'Tab' controls here: https://github.com/microsoft/microsoft-ui-xaml/issues/4492#issuecomment-808375134 and also here: https://github.com/microsoft/microsoft-ui-xaml/issues/4492#issuecomment-808392113

4555 Bring back the TabControl from WPF

As long as its not got Tab in the name I am happy to see a light-weight alternative to the TabView. All throughtout the development of that control I was pointing out uses like toolbar and property panes where the control should be made suitable for.

After having considered this more, I'm not sure TabView and TabControl names are actually an issue if both end up in the framework. We have around 6 different buttons and it's clear what they are all for. Then things like ToggleSwitch, ToggleButton and CheckBox are all conceptually the same but different designs for different use cases. I think developers would quickly learn the difference between a general-purpose tab control and top-level document-style tabbed navigation.

Noemata commented 3 years ago

@robloo , hadn't noticed the other thread: https://github.com/microsoft/microsoft-ui-xaml/issues/4492#issuecomment-808440383

Pivot is back with a promise to release the source when it gets removed the next time. So a win, win at last!

kat-y commented 3 years ago

Thank you @robloo for opening this issue! And thanks everyone for your great comments! (Restating what I shared on #2310 Sorry for the delay here - to give some explanation, we heard the community's frustration at Pivot's removal from WinUI 3 and we've been discussing if, where, and how any work done to 'fill the gap' could be delivered in WinUI.)

NavigationView and TabView are very heavy controls -- not optimized for dynamic loading, or nesting NavigationView and TabView are designed specifically for top-level navigation. User-interaction is not ideal for a 'TabControl' scenario. TabView specifically is only for 'dynamic document tab' scenarios where re-arranging and closing of tabs is needed. It's not for basic switching between pages of settings. Pivot was an alternative but is now removed in WinUI 3 The 'ButtonGroup' control #2310 does not support both header and content. Code-behind or some fancy and unnecessary XAML (perhaps a SwitchPresenter-like concept?) would be needed to set the visibility of 'tab content' when the selection in the ButtonGroup changes. A TabControl does all of this for free.

I understand a lot of these points. I'll echo what I said on #2310 that I don't see a gap in functionality left if ButtonGroup were to be built. Why should TabControl be built to handle horizontal selection + inline XAML content for free? Is it hard to use ButtonGroup + other controls to replace Pivot otherwise?

What if ButtonGroup was wired to a view control in Windows Community Toolkit (like @mdtauk suggested in #2310 ) ?

In order to not split this too much, I'll try to keep the discussions around ButtonGroup and TabControl in their own issues.

robloo commented 3 years ago

@kat-y I'm going to very blunt:

  1. Have you personally ever developed applications before? What about with XAML? If you had I think you would quickly see the value in a stand-alone TabControl.
  2. Nearly all UI toolkits I'm aware of across Linux, macOS, iOS, Android and historically Windows have had a TabControl. It's there for good reasons: It improves developer productivity and standardizes a common UI pattern for both developers and end users.

It is entirely possible to use a TabStrip/ButtonGroup header connected to a ViewSelector/SwitchPresenter. However, this will not be nearly as intuitive for developers. Doing so would also inevitably lead to lots of different implementations which would visually look different or have different interactions with end users (confusion). I would also have to see a rock-solid proposal for how to connect the two controls in code before I felt comfortable with this direction. Finally, don't underestimate how useful it is to have the content and header together for data binding as discussed above.

I am at a complete loss for words Microsoft has thrown out the TabControl in concept and now no longer sees why it's needed. I'm all for new ideas but this is quite a frustrating situation and frankly inexcusable.

SavoySchuler commented 3 years ago

I am at a complete loss for words Microsoft has thrown out the TabControl in concept and now no longer sees why it's needed. I'm all for new ideas but this is quite a frustrating situation and frankly inexcusable.

@robloo Please avoid take this to the extreme - your request has not been thrown out, @kat-y is just giving it the expected investigative diligence to understanding what the current best alternative is and to source your thoughts on the subject. My expectation is that team members will be always attentive to first asking fundamental questions: _"Have you tried something else? What was missing from that thing? Are there alternatives almost do the right job but just need some minor improvements? Alternatively, if we do need a full-sail new solution, what are somethings the closest alternatives didn't get right that we need to be sure we can improve here?"_ This line of fundamental investigative/explorative questioning is what allows us to genuinely understand your experience/needs/pains/etc. (not our own) and then represent them with your voice in our internal discussion. Getting frustrated with our team members does not help them do that job better.

How we can go about these necessary steps in a way that represents itself as collaboratively and as outcome-focused as we intend it to be? I ask because I feel it is very difficult for our PM team members to give their expected due diligence to this line of investigative/explorative questioning without some contributors who, despite otherwise being incredible and impassioned, unfortunately reading it as A) extreme naivety from our team members or B) adversarial undermining/disinterest - which couldn't be further from our goal of trying to advance your interests and build them into the platform.

@kat-y I'm going to very blunt:

Have you personally ever developed applications before? What about with XAML? If you had I think you would quickly see the value in a stand-alone TabControl.

This is not bluntness, it is just rude and is nether collaborative nor helpful. It expected that everyone will take the time to coat their responses in a layer of empathy. Review our Code of Conduct to understand the expectations we have for everyone on this repo; further, consult the Contributing Helpful Feedback guidelines to understand the role these investigative question play in creating the chance for your request to get approved. @kat-y is your ally and is sourcing information to "unlock the gate" on your behalf, she is not the gatekeeper.

=================

Let's keep this mind and try to continue with the conversation....

It is entirely possible to use a TabStrip/ButtonGroup header connected to a ViewSelector/SwitchPresenter. However, this will not be nearly as intuitive for developers. Doing so would also inevitably lead to lots of different implementations which would visually look different or have different interactions with end users (confusion). I would also have to see a rock-solid proposal for how to connect the two controls in code before I felt comfortable with this direction. Finally, don't underestimate how useful it is to have the content and header together for data binding as discussed above.

This seems like a good point. @kat-y, thoughts on this?

robloo commented 3 years ago

I am at a complete loss for words Microsoft has thrown out the TabControl in concept and now no longer sees why it's needed. I'm all for new ideas but this is quite a frustrating situation and frankly inexcusable.

@robloo Please avoid take this to the extreme - your request has not been thrown out,

With the removal of the Pivot in WinUI 3 (before it will be added back this year for previews) Microsoft most certainly has 'thrown-out' the concept of a TabControl. This issue exists because there is a gap in functionality for a general-purpose tab control that has been discussed extensively elsewhere. I was not referring to throwing-out or closing this issue by itself -- the wording could have been clearer above. I was referring to Microsoft forgetting that a TabControl is a fundamental and standardized piece of UI frameworks and incorrectly thinking other controls were simple replacements.

My expectation is that team members will be always attentive to first asking fundamental questions

My expectation is that Microsoft internally has the know-how and vision to avoid asking the obvious fundamental questions and taking up everyone's time. The frustration here is that it somehow isn't obvious to Microsoft that there is a feature gap the TabControl could close. This could be explained if there isn't enough hands-on experience. This is much more pronounced now considering WinUI 3 is geared for desktop apps. Desktop apps with no TabControl? TabControl has been around in Win32 MFC, WinForms and WPF. I should NOT have to explain to Microsoft why this control is useful. You should be explaining to me.

Have you personally ever developed applications before? What about with XAML? If you had I think you would quickly see the value in a stand-alone TabControl.

This is not bluntness, it is just rude and is nether collaborative nor helpful. It expected that everyone will take the time to coat their responses in a layer of empathy. Review our Code of Conduct to understand the expectations we have for everyone on this repo; further, consult the Contributing Helpful Feedback guidelines to understand the role these investigative question play in creating the chance for your request to get approved. @kat-y is your ally and is sourcing information to "unlock the gate" on your behalf, she is not the gatekeeper.

Many times engaging in this repository it seems the gatekeeps of initial ideas do not come from a strong background with XAML UI frameworks. Having to re-explain first principles is time consuming and likely should be discussed internally at Microsoft first. I think it is important to understand what level of experience others have when talking about things like this. Otherwise, my previous points stand above -- Microsoft should know well about the TabControl and why it's useful. I did not invent any new concepts here as I'm clearly just asking for the WPF control to come back. Why was this control deemed useful in WPF? If you answer that question for WPF you also answer it here for WinUI and Microsoft can ask that internally. That would be due diligence on your part.

We have had this conversation at least two other time @SavoySchuler. I have a lot riding on WinUI/UWP and Microsoft's historically shaky direction has been more than frustrating -- it is costing money. If I don't use strong wording you do not prioritize issues. I am consciously fighting my way up the priority stack to get issues addressed that otherwise would be ignored for more pressing matters. You simply don't have enough time/resources to address everything at this point. If you did we would see NumberBox v2 by now. There is no perfectly polite way to shine light on issues.

This seems like a good point. @kat-y, thoughts on this?

Don't forget the initial rationale in the issue description as well.

SavoySchuler commented 3 years ago

Hi @robloo, I think you bring up some fair points and, for what its worth, I am genuinely interested in improving this repo, our processes, and the quality you experience as a collaborator, contributor, and customer of the platform. Would you please reach out to my email address, saschule@microsoft.com? I tried find yours, but it didn't appear to be available on your profile. I'd like to find some time for us to chat offline, maybe even over a Teams call if you're interested, so that I can build big picture understanding of your experiences & problems and chat through some ideas with you on how we/I can improve.

I have a lot riding on WinUI/UWP and Microsoft's historically shaky direction has been more than frustrating -- it is costing money.

Considering this, I my interest in your situation is general - we can include chatting about some specific pain points, like this one if warranted, but I'd really like to touch base on everything going on so that I can figure out the most meaningful way for us to be helping here, see if I can help, and then we look at the right next steps for specific discussions or area owners to include.

If you're open to this, I really look forward to your email. If not that's OK, I'll defer back to @kat-y to continue the primary conversation here, but do know we're interested in helping as best we can.

robloo commented 1 year ago

Still would be nice to finish off the discussion of TabView vs. TabControl vs. Pivot