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
- Terrain is flickering when adjusting "Compatibility Mode" and "Use Rendering Layers" Settings
- Isometric tiles are flickering and overlapping each other when entering Play Mode with Tilemap Renderer mode set to "Chunk"
- Crash on ParticleSystemParticles::array_reserve when particle system starts
- Docking Text Property Preview Window next to UI Builder breaks the window and causes NullReferenceException
- Renderer Light Probe Selection option resets to default when closing and reopening the Unity Editor
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".