TabWidget: Add orientation property to TabWidget

[taichi765]

Summary

This PR adds an orientation property to TabWidget (Material style only), allowing the tab bar to be displayed vertically.

Related issue: #3688

Example

TabWidget {
        orientation: Orientation.vertical;
        Tab {

        }
}

Notes

• @children inside if is not yet supproted, so the implementation switches between two internal components at compile time.

export component TabBarImpl inherits TabBarBase {
    Flickable {
        if root.orientation==Orientation.vertical:VerticalLayout {
            @children// The @children placeholder cannot appear in a conditional element
        }
        if root.orientation==Orientation.horizontal:HorizontalLayout{
            @children
        }
    }
}

• Because of this, runtime bindings for orientation are not supported.
  For example:

component MyTabs {
    in property <Orientation> orientation;

    TabWidget {
        orientation: root.orientation;// this will be ignored
    }
}

Questions

• Is the compile-time switching approach acceptable for now?
• Is there a better way to implement vertical tabbar?

[CLAassistant]

All committers have signed the CLA.

[ogoffart]

Thanks for opening a PR.

I think this is a feature we should have.

Is the compile-time switching approach acceptable for now?

I'd say so, yes.

Is there a better way to implement vertical tabbar?

I'm afraid all the other ways would required change that would be more complicated (but that we probably still want)
Either:

1. Add a OrientedLayout that has an orientation argument at runtime (name to be bikeshedded)
2. Use a GridLayout and have the compiler set the row/col for the individual tab
3. Not use a XXXLayout in TabBarImpl, but have the lower_tabwidget pass have the equivalent of a OrientedLayout despite that wouldn't be in the Slint language.

(Supporting @children in if would have the problem that it wouldn't be possible to reference the item anymore, unless we use other trick like a switch or something where we have @children on each branch or have a more complex language feature which is out of scope for this)

So thinking of it, the OrientedLayout seems to be the easier, and it could even be kept internal.
But as I said, I think it is fine to keep it compile-time constant for now.

Btw, if making it a const expression, we should also forbid assignement like so:

slint/internal/compiler/typeregister.rs

Lines 494 to 495 in 65fb303

	popup.properties.get_mut("close-policy").unwrap().property_visibility =
	PropertyVisibility::Constexpr;

and make it an error when it is not specified at compile time.

[taichi765]

Thanks for the advice!
I've added it.

Remaining tasks:

• Update Cosmic tabwidget
• Update Cupertino tabwidget
• Update Fluent tabwidget
• Update Qt tabwidget
• Write test

Is there anything else?

[taichi765]

With the Qt style, I was able to arrange the tabs vertically and put the tab bar to the left of the content, but the tab titles are missing.

[taichi765]

With Qt style, I was able to arrange the tabs vertically and put the tab bar to the left of the content, but the tab titles are missing.

Now I'm seeing the expected appearance.

Qt style:

However, tab alignment in Qt is very different from others (Qt is flex-start, others are stretch).
@ogoffart Should we make the same alignment across them?
If so, which one should we follow?
In my opinion, flex-start looks tidier for a vertical tab bar, so I'd like to use it in non-Qt styles —but making it the default would be a breaking change to existing behavior.
Alternatively, should we add an option to configure alignment?

Fluent style:

[ogoffart]

From the description, I was thinking that the text would be rotated for the vertical tabs.
But Ok, it can be done like that too.

There is no such tab in the design file from the fluent design so i think we can make our own.

I think we should indeed align the tab to the top. But we don't need to change the behavior of the horizontal ones.

@NigelBreslaw Do you have opinions about that?