It was the initial bug, but while looking at it, I noticed that the MultilineEditableTextBox was containing both a Font via FEditableTextBoxStyle, and another one via FTextBlockStyle, thus being error prone / inconsistent.
In order to fix the underlying issue (in addition to fix the initial bug), I removed the Font from FEditableTextBoxStyle, and moved the FTextBlockStyle from MultilineEditableTextBox to FEditableTextBoxStyle.
It solves the duplication issue and so make it clear where the Font should be set/read from.
However, as the text block style is now embedded in the editable text box style, it cannot be initialized the exact same way, and I had to do some changes to ensure there was no regression, by configuring various FEditableTextBoxStyle in some style files. I also change the default value for TextBlockStyle to better match our default theme.
-Default font is not set for text widgets.
EditableWidget: ensure to have a default font, and to set the style when calling SynchronizeProperties to ensure it reacts directly without having to force a refresh (by moving the widget for instance)
Bonus:
-Move to cpp some private methods that where 'forced' inline (and we were using function pointer on them). It will avoid some noise in public interface and speed up iteration / compile time when playing with them.
#jira UE-96464
#jira UE-137126
[RN] MultilineEditableTextBox was containing both a Font via FEditableTextBoxStyle, and another one via FTextBlockStyle, thus being error prone / inconsistent.The Font from FEditableTextBoxStyle has been removed, and the FTextBlockStyle moved from MultilineEditableTextBox to FEditableTextBoxStyle. It solves the duplication issue and so make it clear where the Font should be set/read from.
However, as the FTextBlockStyle is now embedded in the FEditableTextBoxStyle, it cannot be initialized the exact same way, and you can now configure the FTextBlockStyle of FEditableTextBoxStyle when creating one from scratch, by calling SetTextStyle on it.
Test
- created a Widget blueprint with different editable types combination: multiline or single line, box or no box.
-Validated that everything was reacting live as expected now.
-Created a blue print to set the text style and validated it was working.
-Create data with old version, then open it with updated version to validate that the visual was still the same and deprecation of style working as expected.
-checked different places in the editor using variation of editable text to ensure they were behaving as before (detail view, console command entry, comment on blueprint node).
#preflight 63344b9f110bb3721ef8aa77
[CL 22232366 by yohann dossantos in ue5-main branch]
#fyi Matt.Hoffman
Original CL Desc
-----------------------------------------------------------------
Editor: Ctrl + Console Key (` by default) now iterates through active Console Command Executors, so you can switch between Cmd and Python by hitting Ctrl + `.
#jira None
#rb Yafes.Sahin, Rob.Millar
#preflight 629a542d5818a74ce53fd524
[CL 20497486 by matt hoffman in ue5-main branch]
This represents UE4/Main @17774255, Release-5.0 @17791557 and Dev-PerfTest @17789485
[CL 17794212 by aurel cordonnier in ue5-release-engine-test branch]
- You can now choose to color-code entire log lines by category, or just the category itself (CategoryColorizationMode in editor appearance settings)
- You can also choose to highlight all messages for a particular category by right-clicking on a line
- Also includes plumbing to expose GetCursorLocation up to SMultiLineEditableTextBox
- Known issues: If you edit editor appearance preferences after scrolling (but not clicking) in the output log, the view in the output log will be snapped to the last clicked cursor location
#jira UE-119864
#rb jamie.dale
#ROBOMERGE-SOURCE: CL 16941163 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v838-16927207)
[CL 16941172 by michael noland in ue5-release-engine-test branch]
