+basic filter bar not close entire menu stack in case the filter bar is used in another menu
#jira UE-223796
#rb sebastian.arleryd
[CL 36205907 by jack cai in 5.5 branch]
Set the visibility of separators to a delegate that depends on the visibility of previously and upcoming raised entries. This allows separators to only be visible when they are surrounded by raised entries and avoids situations where dynamically raised entries are hidden, leaving separators as the first or last elements in a toolbar.
This is needed for the new viewport toolbar. We raise entries from toolbar submenus (combo buttons) so they appear directly in the top-level viewport toolbar. The condition for raising entries can be dynamically driven by a TAttribute<bool> delegate. We want to add separators between raised entries if said entries either live in separate sections or have an explicit separator between them. Because entries are dynamically visible but we still want to show separators when the entries are visible, the visibility of the separators themselves has to be dynamic which this change supports.
#jira UE-212285
#rb ross.smith
[CL 36033530 by sebastian arleryd in ue5-main branch]
* Add FToolBarButtonBlock::ToolbarLabelOverride and FToolBarComboButtonBlock::ToolbarLabelOverride.
* Add InToolbarLabelOverride to FToolBarBuilder::AddToolBarButton and FToolBarBuilder::AddComboButton methods and forward it to FToolBarButtonBlock::ToolbarLabelOverride and FToolBarComboButtonBlock::ToolbarLabelOverride.
* Use the ToolbarLabelOverride, if set, as the label when the blocks are added to a toolbar. The ToolbarLabelOverride does not affect the label of menu entries representing the blocks in toolbar overflow >> menus.
* Set the ToolbarLabelOverride to the empty string for ToolMenu entries raised to the top-level of a toolbar because our design is for those to not have labels by default. These entries will still have a proper label in the overflow >> menu of a toolbar.
#jira UE-222413, UE-212285
#rb George.Rolfe, Vincent.Gauthier
[CL 36002329 by sebastian arleryd in ue5-main branch]
* Add FMultiBlock::VisibilityOverride.
* Take a new InVisibilityOverride as parameter in FToolBarBuilder::AddToolBarButton, FToolBarBuilder::AddComboButton, FToolBarBuilder::AddWidget, and FToolBarBuilder::AddSeparator and forward to FMultiBlock::SetVisibilityOverride.
* Make SMenuEntryBlock, SToolBarButtonBlock, SToolBarComboButtonBlock, and SToolBarSeparatorBlock all use the visibility of the VisibilityOverride unless it returns Visible, in which case other methods get a chance to affect visibility too (command visibility, for example).
#jira UE-212285
#rb Vincent.Gauthier
[CL 36001772 by sebastian arleryd in ue5-main branch]
* Create a style named "ViewportToolbar" for toolbar entries that currently sets a brighter background color to help visually group the toolbar.
* Create a separate style named "ViewportToolbar.Raised" for any entries raised to the top-level toolbar. Such entries do not get the brighter background because they're a part of the submenu they were raised from and that submenus brighter background will provide the visual grouping hint.
* Apply the new "ViewportToolbar" style to the UToolMenu representing the new level editor viewport toolbar.
* Add the ".Raised" suffix to any set style when an entry is raised to the top-level of a toolbar. Any entry raised within the viewport toolbar (using style "ViewportToolbar") will therefore hit the "ViewportToolbar.Raised" style.
#jira UE-212287
#rb aditya.ravichandran, Dario.Mazzanti
[CL 35596044 by sebastian arleryd in ue5-main branch]
This is to reduce the visual load when raising items to the top-level that already have an icon to identify them.
#jira UE-212285
#rb Dario.Mazzanti
[CL 34636940 by sebastian arleryd in ue5-main branch]
This is useful when raising a menu entry to the top-level toolbar. The original label is used for the menu entry and the override for the toolbar.
#jira UE-212299
#rb JeanMichel.Dignard
[CL 34599491 by sebastian arleryd in ue5-main branch]
This prevents duplicated raises entries in toolbars when a child submenu is raised and a child of that child (grandchild) is also raised. With this change, the child and the grandchild both appear once in the top-level toolbar. Before, the grandchild would appear twice, raised once via the parent and once via the child.
#jira UE-212299
#rb JeanMichel.Dignard
[CL 34599423 by sebastian arleryd in ue5-main branch]
The new alignment support layers on top of the existing insertion-order support. Sections are added to the toolbar in groups where we first add all Left-aligned sections according to their insertion order, then all First-aligned sections, and then the Middle and Last-aligned sections. Note that this can break the specified insertion order if the user mixed alignments, but otherwise it's maintained.
The First and Default alignments are grouped together, with First-aligned sections appearing before Default-aligned sections. The result is a toolbar with visual empty space between the First-Default group, Middle group, and the Last group. A caveat here is that the Middle group won't necessarily appear perfectly centered on the toolbar because it's position depends on the sizes of the First-Default and Last groups.
#jira UE-212286
#rb brooke.hubert, ross.smith2
[CL 34230831 by sebastian arleryd in ue5-main branch]
The upside of this is that the submenus of each group ("section submenus") can have proper ToolMenu sections if they are ToolMenu submenus. Previously, when we grouped using sections, we couldn't section each section, because ToolMenus doesn't support nested sections.
#jira UE-212288
#rb ross.smith2
[CL 33935309 by sebastian arleryd in ue5-main branch]
This applies if the toolbar section has a section menu. In that case, the toolbar section itself will from now on be populated with recursive children if those children are flagged to show up in the toolbar top level via FToolMenuEntry::SetShowInToolbarTopLevel(bool).
Note: to update the top-level status of a grandchild, you might need to call UToolMenus::RefreshMenuWidget for the new top-level status to be reflected in already generated widgets.
#jira UE-212289
#rb brooke.hubert, ross.smith2
[CL 33822129 by sebastian arleryd in ue5-main branch]
This flag has no effect if the toolmenu section does not have a section menu.
Note that this change will not display recursive children of the section in the toolbar section even if they are flagged to show in the top level. Only direct child entries of a section with a section menu can be displayed in the top level for now.
#jira UE-212289
#rb ross.smith2
[CL 33764220 by sebastian arleryd in ue5-main branch]
A section menu is currently only rendered for toolbar sections. The section menu can be opened via a new combo button that is added as the left-most entry of toolbar sections. When that combo button is clicked, a menu opens containing all entries of the section.
Section menus are disabled by default, but can be enabled on a section by calling the new FToolMenuSection::SetShowSectionMenu(bool) API.
#jira UE-212288
#rb aditya.ravichandran
[CL 33626872 by sebastian arleryd in ue5-main branch]
Also update the text to match another warning message. This warning fires when a menu-type ToolMenu iterates its entries to populate a menu builder but finds an entry that menus don't support, such as a toolbar button.
#jira UE-196906
#rb aditya.ravichandran
[CL 32788630 by sebastian arleryd in ue5-main branch]
Setting UToolMenu::bSearchable to false in a menu delegate will now disable the search field completely for that menu (hidden and non-functional even if the user types into the menu). However, menu entries from this unsearchable menu will still show if a parent menu is searched.
#jira UE-208812
#rb brooke.hubert
[CL 32081852 by sebastian arleryd in ue5-main branch]
This fixes a crash on hovering over the "transform" submenu in the light mixer context menu
#jira UE-203032
#rb Jamie.Dale
[FYI] Jason.Walter
[CL 30778338 by aditya ravichandran in ue5-main branch]
