Search Issue Tracker
Won't Fix
Votes
0
Found in
2020.3.39f1
2021.3.11f1
2022.1.20f1
2022.2.0b10
2023.1.0a12
Issue ID
UUM-19340
Regression
No
Preferences setting appears different than specified in the UI Document
How to reproduce:
1. Open the attached “VSElementBug“ project
2. Select “Edit” → “Preferences…” → “Test Settings” in the main menu
3. Open the UI Builder window by opening Assets\Plugins\TestProvider\Resources\Layouts\”TestDocument”, or select the UI Document and observe the preview image in the Inspector
4. Compare the Test Settings window to the one in the UI Builder
Expected result: Both windows are identical
Actual result: The “Button” button in the Test Settings window is at the top right corner instead of the bottom right one
Reproducible with: 2020.3.39f1, 2021.3.11f1, 2022.1.20f1, 2022.2.0b10, 2023.1.0a12
Reproducible on: Windows 10
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Memory leak occurs when focused on Player while using Direct3D12
- var VisionOSEDRHeadromm has a comma instead of a dot when building with Metal Rendering App Mode and local OS localization is set to German
- IAP Catalog remove product “x” and add product “+” buttons are not consistent with other remove and add buttons in the Editor
- Performance issues in Play Mode when quickly hovering the mouse cursor over Hierarchy GameObjects
- Frame Debugger displays incorrect output when FidelityFX Super Resolution or Spatial-Temporal Upscaler is used with Temporal Anti-aliasing or Subpixel Morphological Anti-aliasing
Resolution Note:
I understand that it's not ideal to be unable to easily create the layout you'd like in the Settings window. The Settings window, just like the Inspector, is designed to be a "scroll area" where content takes only the space it needs and if it needs more space than available, as ScrollView (that you don't control) makes sure your UI is still accessible. All Settings panes use this same ScrollView parent so that it's not necessary for each pane to implement its own (likely unique) scrolling UX.
What you're trying to do goes against the UX pattern established in the Settings pane, hence the blockers. If you _really_ want to create something unique (for the Settings window), you definitely can, but you'll need to jump through some hoops.
Those hoops require the creation of custom parent VisualElement that walks up the UI tree, finds the parent ScrollView, and registers a GeometryChangeEvent callback on it. With this, you can always get the current size of the ScrollView and size your contents so that they always take exactly that size (never invoking the scroll bars). You can then create your own ScrollView inside for the dynamic part of your UI.
You're not wrong that alternate layouts should be easier, and we might invest in this in the future, but it doesn't make the current setup a "bug".