Support ToolWindowContainer alignment within auto-hide containers

Hello,

Thank you for the suggestion. We can see the value in placing some auto-hide tab groups at the near end of a side and others at the far end.

The current auto-hide tab strip arranges its ToolWindowContainer groups sequentially using a stack-style layout. Supporting two aligned regions would require a custom layout panel, including implementing overflow behavior for cases where the near and far groups require more space than is available. Because of that, this would be a larger feature rather than a quick alignment property.

There is also a model question we would need to resolve. ToolWindowContainer instances are created and destroyed dynamically as docking layouts change, so an alignment setting would likely need to be associated with each ToolWindow instead. However, auto-hide tabs are currently grouped and positioned by container. If one container contained tool windows with conflicting near and far settings, it would be unclear where that container should be placed or whether the group should be split.

We like the general idea and will keep it in mind for future consideration, but we would first need clear rules for those grouping and overflow cases. What behavior would you expect when near- and far-aligned tool windows are grouped together?

Hello,

That makes sense.

My first thought is that a container should only have one alignment. It should be either near or far, but not contain a mixture of both.

Since the containers are created dynamically, the alignment could belong to the individual ToolWindow and then be used when the auto-hide groups are created.

For grouping, I think these rules would make sense:

• ToolWindows with the same alignment can be grouped normally.

• If a group contains both near- and far-aligned ToolWindows when it is moved to auto-hide, split them into separate groups.

• If the user deliberately drags a ToolWindow into an existing auto-hide group, have it adopt that group’s alignment.

• ToolWindows without an explicit alignment could use the current default behavior or inherit the alignment of the group they join.

• The flexible space between the near and far groups would disappear first as the strip fills. After that, normal overflow behavior could take over.

So, generally, I would avoid allowing conflicting alignments inside one container. Automatic operations would split them, while an intentional user grouping action would make the moved ToolWindow adopt the target group’s alignment.

That seems like it would keep the behavior understandable without tying the setting to a container that may later be destroyed and recreated.

Thanks