Fix Combo popup size and position

[Tazmondo]

Fixes #90

The commit that edits the demo window can be undone if not desired, but it was useful in testing my solution.

I'm not sure if adding the UIListLayout to the Combo type fits with how the codebase is structured, please correct me if there's a better way of getting a reference to the UIListLayout.

The idea behind how the positioning works is:

• Try and extend the list downwards first.
• If this results in it going off the screen, and there is more space above than there is below (the origin is in the bottom half of the screen), then extend upwards instead, so as much of the selection as possible is visible.
• If there is more space below, then extend downwards as normal.
• In both cases, the size is constrained to the edge of the screen so you can scroll to see all the available options.

Also I've noticed there is similar popup behaviour for the Menu widget - I have not investigated or used it myself but it may benefit from similar changes being made to it?

[Tazmondo]

Demo video:

Screen.Recording.2025-01-19.000317.mp4

[Tazmondo]

Seems like setting the AutomaticSize to Y just overrides the size property and brings us back to square one, with the combo going off-screen again when there are many elements.

It would be ideal if we could recalculate the size whenever the contents are changed, but I'm not sure if there's already some infrastructure to allow for that or if it would have to be added in. I see a ChildAdded event here but we'd need a DescendantAdded and DescendantRemoved.

An alternative would be to, while there is a combo open, just cache the UIListLayout.AbsoluteContentSize.Y value, check if it has changed each frame, and if it has then recalculate the size and cache the new value.

[Tazmondo]

This should fix it while hopefully fitting the style of the codebase? Performance should also be fine, the UpdateChildContainerTransform is only run once when the combo opens or when the contents change.

[Tazmondo]

Demo Video:

Screen.Recording.2025-01-19.190335.mp4

The combo menu flipping upwards after you extend the contents doesn't feel great, but I think it'd also feel pretty bad if it didn't flip and a large number of items are now off the screen, so it should be fine to leave it as it is.

[SirMallard]

Yeah, I realised this issue, but forgot to add a comment to let you know. I was hoping to use the UISizeConstraint within to limit the size whilst also allowing the AutomaticSize to work. However, there is a bug which means that the AutomaticSize does not respect the UISizeConstraint, https://devforum.link/1391918.

Instead, I would be happy to just leave the odd behaviour, since closing and reopening the combo will always resize it. I don't know whether I would rather have a function constantly checking for updates, or just be happy leaving it slightly broken (for now).

[Tazmondo]

Yeah that probably would have been the ideal solution, but alas.

As for whether to keep the odd behaviour or keep the function, I do lean towards keeping the function there.

I can definitely see how it doesn't really fit with Iris' approach to things, and isn't an ideal solution, but I think it's better than settling for janky behaviour.

The pattern of some widget type running code each frame is already used for tables. (https://github.com/Tazmondo/Iris/blob/main/lib/widgets/Table.lua#L9-L13)

The performance impact of a couple if statements and a property index each frame, and only while you have a combo open, should be pretty negligible. The more expensive part is only run when it needs to.

Regardless, if you'd like I can revert the change.

[SirMallard]

Yeah, it's a Roblox issue that prevents it from having a better example, so we'll accept the slight cost. But I like the caching.