Iris Text and Window Changes
Closed this issue · 6 comments
I presume this just means enabling the RichText property on a textlabel. I might just add it to the default text and implement an alias like I've done with TextColored and TextWrapped.
On second thoughts, I'll just add it as an individual argument. I don't want to clutter the API with aliases. Eventually we'll probably deprecate 'Iris.TextWrapped' and 'Iris.TextColored' in favour of using 'Iris.Text'.
To put into more concrete terms the changes SirMallard mentioned above:
• Depreciate Iris.TextColored, Iris.TextWrapped and proposed Iris.TextRich for Iris.Text
• Include new arguments Color, Wrapped, Rich for Iris.Text Widget.
• Introduce new config properties TextRich and TextWrapped, similar to existing TextColored. These will affect all widgets with text. In the case of Iris.Text the arguments will override the config properties when specified
@Michael-48 I've added these features to Iris. This means that every text item in any widget will pass through the applyTextStyle method which will update it to be either RichText or TextWrapped depending on the config and the arguments.
It was fairly straight forwards to add, and I updated the config page in the Demo Window to include config options that were not previously changeable from there. This included adding the RichText and TextWrapped config options. Since these options apply to all elements including Window titles, text can wrap in these elements.
However, when enabling TextWrapped, the sizing fails on the windows and a large gap appears between the Title and ChildContainer. This is because the code which sets the position of the ChildContainer only onces once and depends on the AbsoluteSize of the Title, which may change when first drawn, thus producing these gaps.
This also reminds me of implementing MenuBars where I had to update the Window to accommodate them, which was rather sneaky and didn't seem like a good solution, but I couldn't find another one which worked well enough. However, with the addition of UIFlexItems, this could be solved by making the ChildContainer a fill element to use the excess space. This would make it much easier to deal with, but would require the alteration of the structure of elements in a Window widget.
Do you think this would be a good change to make, also bearing in mind that they are still in Beta and would not work in-game yet?
Great work. The issues regarding sizing remind me of this which evaera wrote about the development of plasma
immediate mode ui has problems with layout the obvious example is centering something like centering a window.
you can't put the window in the center because you don't know how big it will be when you make it, it doesn't have its children yet
a lot of immediate mode UI libraries solve this by doing a multi-phase update, where on the first frame something is not laid out correctly and then on the second frame it uses the layout from last frame
we mostly bypass this problem with plasma though because plasma just updates retained mode ui elements that have listeners that resize the window when there are more children added
I didn't necessarily understand this issue when developing Iris, because roblox UI instances are just dynamic enough that with a smart layout of instances they can handle resizing and Changes automatically without having to update them... To an extent.
To keep with the principal of Roblox Instances handling all of the changes automatically, there is some sneaky workaround in existing widgets, like the Separator widget including this line:
widgets.UIListLayout(Separator, Enum.FillDirection.Vertical, UDim.new(0, 0))
-- this is to prevent a bug of AutomaticLayout edge case when its parent has automaticLayout enabled
which exists just to provoke the UI to update sizing when it otherwise wouldn't've. It appears that the two idioms to solve this issue are to
- account for property changes through event listeners, as is done in plasma and in Menu.
- try and take advantage of clever UI layouts to avoid ever having to keep track of updates
Personally im leaning towards the second option.
As for the latter we might need to look further into the new UIFlexItems to see whether its a viable alternative.
Also, I don't think the Beta status of UIFlexItems should interfere with development of Iris, though i don't have the figures for how long features like this may stay in beta.
I've had the chance to work on and finish the Windows update. This allows Window Titles and MenuBars to have RichText and WrappedText properties on them and not break the UI. While I would advise against this, it does work. The fixes have been added to the main branch and partially on #43 (I had already commited some to main) where it explains what changes have been made.
I think it's safe to close this issue now then! 🎉