Question Vertical Spacer

Hi! I am just starting to work with UI Toolkit as one of my projects is on 2019.4 and requires a custom UI (custom editor) and I figured I would follow best practices and implement both IMGUI and UI Toolkit.

I am building out the VisualElement entirely in code as I find it faster/more familiar. As such I am simply adding elements to a root element in code to get the job done as the layout is fairly straightforward.

I would like to add some vertical space between elements. To do this, I would much rather start building up a library of small, reusable UI Toolkit fields so I created a SpacerField script, as follows:

Code (CSharp):

1. using UnityEngine.UIElements;
2.  
3. public class SpacerField : VisualElement
4. {
5.     public new class UxmlFactory : UxmlFactory<SpacerField, SpacerField.UxmlTraits> { }
6.  
7.     public new class UxmlTraits : VisualElement.UxmlTraits
8.     {
9.         public override void Init(VisualElement ve, IUxmlAttributes bag, CreationContext cc)
10.         {
11.             base.Init(ve, bag, cc);
12.             ve.style.height = 12;
13.         }
14.     }
15.  
16.     public override bool canGrabFocus => false;
17. }

I then iterate over the serialized elements in an array (serializedProperty) and draw each with a spacer afterward.

Code (CSharp):

1.  
2. ...
3.             SerializedProperty serializedRegions = serializedObject.FindProperty(MEMBER_REGIONS);
4.             for (int arrayIndex = 0; arrayIndex < serializedRegions.arraySize; ++arrayIndex)
5.             {
6.                 SerializedProperty elementProp = serializedRegions.GetArrayElementAtIndex(arrayIndex);
7.                 indentedContainer.Add(new PropertyField(elementProp));
8.                 indentedContainer.Add(new SpacerField());
9.             }
10. ...
11.  

This does not add any visual space and, using the debugger, the SpacerField has a height of 0.



What is confusing is, Using the UI Builder, if I drag in a SpacerField, it works as intended



I am pretty certain this is simply a case of me not understanding styles/how to override them for an individual element, but the inconsistency is definitely confusing and some guidance would be appreciated.

 

Thanks! That explains the difference between inspector and UI Builder!

One last question: if moving this logic to the constructor, it looks like I can drop the UxmlTraits entirely. Is that a correct assumption or will there be cases when using uxml where it will still be necessary?

 

That's a solid suggestion! I already allow a custom height to be passed in via code int eh constructor but wanted to also make sure other use cases (a non-technical dev or building a larger editor with uxml and uss) would still be a viable approach and provide flexibility needed.

If I leave the inlining in the constructor, would that still play nicely with uss? I'd like to avoid needing to include uss for every editor as I am far more comfortable doing everything in code and find iterating and debugging quicker.

Thank you!

Update

The inline style will always override the uss value, which I guess makes sense. Is there any other way to be able to set the height via code only and avoid creating an additional uss file, but still allow it to be overridden later if uss is added? I have added a class name to my visual element via

AddToClassList("spacer-field")

.

I'm currently looking at the styleSheets property and wondering if there is some way to get the style sheet currently used to render the UI and read the value from there and, if there is no uss for the "spacer-field" class, default to whatever is passed in code.

 

Yes, that makes sense. I've already implemented a two constructor version where the height can be overridden, but it's good to know that is an approach shared by others.

I've done this for now and it works fine for my current use case. In general, I rely heavily on having many small, specific packages I share between projects. Since I try to keep them focus and modular, I'll eventually need uss files for each since many do not have dependencies on each other. I don't mind creating them, I just prefer having fewer files to get a job done.

Related to the above: is there any way to change the order in which uss are applied, specifically with respect to the buily in uss files? I have been trying to create a simple indent that shrinks the label but leaves the input field the same size, like a foldout, but there are many cases where the container overrides the build in uss which results in some ugly layouts and a lot of rewriting functionality of the built in uss.

 

I wrote up the lengthy post below and near the end something I in my own uss made me think to try a slightly different approach which made the specific issue below solvable within my own uss without the need to copy attributes from the base uss by using the > symbol to specify direct child. Without any background in web development I have a fair bit to learn about what is possible with uss.

I'm leaving the issue below in case this issue is possible in some other setup that I can't think of right now.

--------------------

Yes, I've been using the debugger extensively (and how I realized I was overriding some settings which was causing
some ugly styling).

I was trying to create an indented set of properties. I'll explain the specifics of what I am trying to accomplish.

I have started using SerializeReference in order to serialize standard C# classes that implement a specific interface. My use case is currently an interface for damage volumes but that doesn't have any bearing on the issue.

My current approach is to use an attribute to above the interface to create a popup field that will be populated with all implementations of interface. Selecting one will update the object and draw the selected interface implementation beneath. Since this is a nested object, I wanted to have it indented, much like the built in foldout. I applied a margin of 15px, same as the foldout, but noticed the label and input field scaled proportionally as opposed to keeping the input fields lined up and only indenting the labels.



Yes, I realize this is a very minor issue but I was curious as to how to solve it. I went back to the debugger to find the foldout settings for the main container and nested labels and copied them into my own uss.

Inside that indented container I manually draw all the serialized properties of the object instance. All seemed to work until I went to render a vector field and it looked like this:



The Vector property field was scaling incorrectly making the input fields inaccessible. I had overrode the

.unity-composite-field__field .unity-base-field__label

rule from the default uss. I then had to recreate the rule in my own uss because I couldn't change the order of the stylesheets.