Allow TabContainers to position some child nodes in the tabs bar

[groud]

Describe the project you are working on

Godot

Describe the problem or limitation you are having in your project

While working on the editor, I often want to be able to add some controls next to tabs. It is technically possible by using Tabs nodes, but it does not provide the ease of use TabContainers are useful for.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

To simplify this use case, I would like to add an option to TabContainers allowing to use the first one or two children to be placed in the tabs bars, next to the tabs. We have something similar in the editor, but they cannot use a TabContainer. Here with the buttons with 3 dots:

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I think the way to expose this option would be an enum with 4 values:

• Default
• Use first child in tabs bar (begin) -> positions the first child control to the left of the tabs bar.
• Use first child in tabs bar (end) -> positions the first child control to the right of the tabs bar.
• Use two first children in tabs bar (begin and end) -> positions the first child control to the left of the tabs bar, and the second one to the right.

We could use two booleans too, that would work too I suppose. Additionally with booleans, we could also allow two other areas behaving the same way, but next to the tabs. That would allow for something similar to the plus button we have in the editor, next to scenes tabs.

If this enhancement will not be used often, can it be worked around with a few lines of script?

I guess, at least it would be used often in the editor. Can be workarounded but it's not easy to do.

Is there a reason why this should be core and not an add-on in the asset library?

This is core.

[Jummit]

Duplicate of #2129 (comment)?

[YuriSizov]

Duplicate of #2129 (comment)?

Not exactly, but as an alternative solution, maybe.

[barbaros83]

tab seperation would also be nice to have, where we could define some value to put in between the tabs, like a spacer, would give us the option to make the ui more unique/modern, depending on design choices

[YuriSizov]

We have something similar in the editor, but they cannot use a TabContainer. Here with the buttons with 3 dots

@groud I've just ran into the need for something like this myself, but now I don't get what you mean here. The three dots button are exposed to the TabContainer, but lack customization. You need to set a Popup-derived child via set_popup and TabContainer will generate this button with three dots that will open said popup.

As I now see it, we can easily introduce a couple of configuration options to this to achieve the results we need. Namely, it needs a way to set the icon and a way to change its position. Currently it is always added to the far right, but we can introduce other variants, such as "far left", "to the left of tabs", and "to the right of tabs". The benefit here would be keeping the existing functionality and not relying on child positioning.

So it would be, in GDScript, like this:

var popup_menu = PopupMenu.new()
add_child(popup_menu)
set_popup(popup_menu)
set_popup_icon(get_icon("Add", "EditorIcons"))
set_popup_button_position(RIGHT_OF_TABS)

This can all be done without even breaking the compatibility. If we were to break it, set_popup/get_popup can be replaced with a more generic way to add a button (with options described above) which instead of toggling a Popup would emit a signal and the user would be free to do anything they want with it.

And I don't think that we need more than one button in most cases, but if we do and we do want to break compat, we can make position to be the essential part of setting a popup/button. Something like

set_popup(RIGHT_OF_TABS, popup_menu)
set_popup_icon(RIGHT_OF_TABS, get_icon("Add", "EditorIcons"))

[groud]

@groud I've just ran into the need for something like this myself, but now I don't get what you mean here. The three dots button are exposed to the TabContainer, but lack customization. You need to set a Popup-derived child via set_popup and TabContainer will generate this button with three dots that will open said popup.

Ah I did not know that. I though this was using the Tab node instead.

And I don't think that we need more than one button in most cases, but if we do and we do want to break compat, we can make position to be the essential part of setting a popup/button. Something like

My proposal would not break compatibility. The fact is I need more than one button, as I want to use it to position a toolbar.
That would make things more compact in my case.

[YuriSizov]

I see, so you want a completely custom control there, not just a single button. If I'm being honest, this feels like an overkill to me, mixing tabs with a toolbar. I see the appeal of compactness, but I'm not sure that's the best UX setup.

My proposal would not break compatibility.

Well, it appears your proposal conflicts with the existing functionality, that is used for docks. And to realize it the way you need it, we would have to replace it. Otherwise we'd be left with two ways to do the same thing, one with a bit more flair than the other. Can you reconsider your toolbar into something like a PopupMenu, or moving it outside of the tab bar?

[groud]

I see the appeal of compactness, but I'm not sure that's the best UX setup.

Compactness is very important. And this would help me make the bottom editor a lot more compact. Remember a lot of people are using Godot on 13" laptop screens.

In my case, I wont keep a full toolbar on the top of TabContainer with only two tabs. Se this screenshot:

I don't think this is acceptable.

Can you reconsider your toolbar into something like a PopupMenu, or moving it outside of the tab bar?

No, I'll go for the Tabs node if I cannot do it with a TabContainer. A toolbar cannot go inside a PopupMenu.

Well, it appears your proposal conflicts with the existing functionality, that is used for docks. And to realize it the way you need it, we would have to replace it. Otherwise we'd be left with two ways to do the same thing, one with a bit more flair than the other.

This is not a problem. We could either automatically convert things to the new system, or simply leave both solutions exist and mark the old method as deprecated. So technically, there's not compatibility breakage in adding those two properties.

I mean, the goal of this proposal is to simply make easier something we already do in the editor in several places. I believe the use case is common enough in the editor for adding such feature to TabContainer. But if we don't go for it then that's ok, I'll simply use Tabs instead or find another solution, it's just more work and some duplicated LoC, but that's not a big deal.

[boukew99]

Namely, it needs a way to set the icon and a way to change its position. Currently it is always added to the far right, but we can introduce other variants, such as "far left",

Putting it on the left makes sense for submenus (which flow to the right). Especially when the TabContainer borders to the right edge of the window.

Would be useful for my use case.
Edit: Furthermore, I use it as a main menu, which makes sense to come before the Tabs here.