Reworked, New Property editor / Inspector

[toger5]

The current property editor is using the tree node and than doing some hacky tricks to make it a column based property editor.

Since a property list is a key part of an editor it would be nice to have a coustom class for it which is easier to understand and more flexible.

I opened this issue to discuss how it should look like and plan its implementation. I also heard reduz saying in the internals talk or on irc that this class needs some work.

[Zylann]

I think it had to be a tree at some point due to the sections being collapsible (but they currently aren't, which was also discussed in another issue but I can't find it).

I never had a look at this class yet but I went into creating a few of these inspectors over past works. They usually had folding (which is nice for categories), and had the ability to bind variables to a specific editor according to their types and some flags. I'll write down my thought about it as it's a complex but useful widget to have:

Categories:

• Nice to have, especially with inheritance. The ability to fold them is found on every property editor I know of.

Why is the type not enough:

• Angles in Godot are radians, but when presented in an editor they must be degrees. So a tag is necessary to avoid the addition of methods/properties that would only be useful for non-programmers.
• Sliders: some properties are best modified through sliders rather than a text box, but we don't want sliders everywhere (whether they are 1D or 2D sliders). So values that have no defined range don't need a slider.
• Some integers have a limited set of values (enums, powers of two...)
• Matrices (basis) can be represented in different ways depending on which context they are used (shader specific? Node transforms? pure storage/math?)
• Room for customization in general so people can make their own editors for their properties

Editor fields:

• Once we know which editor to display, then an editor is shown. They are usually simple, and consist at least on a quick preview of the property and can be clicked for a more complete editor if needed (ex: color picker, curve editor...).
• These editors can be Controls, which make them easier to re-use.
• Note about performance: I've seen some GUI frameworks use "impostors" to display editors, because when the edited data is hairy (lots of data changing in realtime) then lots of them have to be drawn. If we find this is needed in Godot that could be implemented with a simple draw() mimick rather than instancing a full-blown node for each field.

Separation of concerns:

• Property editors can edit anything that is key/value based: resources, but also objects (keys are stringnames), arrays (keys are numbers) or dictionaries (keys are strings).
• As a result, a property editor doesn't necessarily need to know what it edits (so no need for a separate implementation for each case). That job can be left to the code that integrates the property editor (Inspector, Project Settings, Editor Settings, debugger, json editor why not).
• Code wise, it would be great if the editor, its specializations and field editors were implemented in distinct locations rather than lots in the same class, to reduce the amount of info contributors have to brain if any change has to be done to this control.

Data binding:

• The property editor needs to reflect the data being edited, so it needs to be receive updates, and send updates. Because it's key/values it can be identified by paths.
• The data can be flowing in two directions (so beware of designs with "onchange" events that could trigger infinite loops! Checking equality usually breaks that loop, but alternatives might exist).
• I often found that MVC-orientation and the like help here, not sure if that's how the current inspector works.

About Vector fields:

• I currently don't like the fact that they should be clicked once to edit them. In Blender or Unity there are 2, 3 or 4 fields in one box directly (or inline) which is more convenient IMO.

About sliders:

• Currently all numerics have one, and require a first click to be shown and changed. As described above, it would be more user-friendly to see them directly and only on relevant ranged fields. Example: properties of the Particles node.
• Because we can re-use slider nodes, that means we can choose wether a slider updates the data as it is dragged, or when it finished dragging. In some cases it is very useful to prevent annoying lags.

About text fields:

• The same as sliders goes for text as it is typed or until Enter is pressed, wether they target numbers or actual text.

About arrays:

• Arrays containing thousands of elements can be a problem to show. If there is more than X elements, maybe it can fallback to a dedicated editor which can show lots of elements. In Firefox, they chose to use ellipsis (like, in an array of 1000 elements, show only cents, then tens, which can somehow be unfolded).

About dictionaries (and arrays too in fact):

• Dictionaries are a type where the keys are editable (wooot!) so the property editor could have this handled, to some extent. Not sure if exotic keys (objects, colors...) are worth implementing? (mostly useful in debugging inspectors).
• Values of a dictionary, but also arrays, can contain nested data so that is another good use for folding.

I have to go home so I'll stop there for now, I hope this helps. I'm curious to see how it goes because that control is used so much in Godot :)

[toger5]

@Zylann I really like the ideas and thoughts you brought up! I totally agree on the approach to remove two stage controls (for example vectors where you first have to click and than get access to the x, y, z value.) in any case where it is possible.

Also the folding is a really good point. Which should be implemented.

Structure wise i would propose the following:

1. Different sections: Each section corresponds to one lvl of inheritence as it is right now: first could be node second could be control third could be button...
2. Property: A property object has two elements to it: the name and the value type. The value type is a little complex because it jas to handle Vectors, colors, text, arrays, int, float, angles, range, nodepaths, enum... Some of them profit from more space, a vector value would be nice to be displayed as 3 number elements in three lines (like in blender)

I also would like to open a discussion about how different value ui elemts could look like. Example: it would be nice to have a special ui for enums like in belnder:

Another idea is to allow for different alignment options: if one property should be displayed in a table like manner, name on the left and value field on the right or name on top and value underneath. Or if the name shouldnt be displayed at all. (in case there will be enum like elements shown in the screenshot above) and the different values provide enough information so no name is needed.

3. Than property objects can be added to a section. The question is, how can they be added. Is it overkill to allow different arrangements: like two vectors next to each other instead of underneath? Or if they just can be listed underneath than each section just consist of an array of properties. Otherwise there has to be a layout system which allows to split a row into multiple columns so two or more properties can be put into one row. Of course that only works with some propeeties. Im thinking about two vectors next to each other. Insparation again from blender:

[Zylann]

About point 1): sections don't necessarily represent a level of inheritance, but can be used as such indeed, which was my point in Separation of Concerns :) Then you can have any number of them, depending on where you specialize the control.

About point 2): the value type should not be complex. I mostly see it as a Variant, kind of. The property editor doesn't need to know all of them in advance, which is a blessing because it simplifies a lot the implementation. Then you would have a mapper that generates the appropriate view/control with some common functionality depending on what value it is. It could be the same for keys but in a way simpler manner (although some exceptions may switch their layout, checkboxes for example, where the key would preferably be on the right).

The Blender example shows a variant: it is primarily a folding container, where each fold contains a list of arbitrary controls. That's really different from the tree approach which is more generic, but the two are not necessarily incompatible (and can even be combined). In Unity this approach is done using procedural composition (calling some layout functions one by one to produce output, a bit like OpenGL or ImGUI) rather than having a predefined structure everything should follow or inherit, however not sure if that fits Godot way of GUI-ing.

Also generally speaking, don't forget that the property editor stays a property editor. If something is too specific/complex/particular to be edited in there, then the viewport docks can be used too for complete freedom (TileSet tile picker, shader editor etc).

[reduz]

I thought about it many times, but the current way offers so much simplicity that it's hard to do away with it

On Wed, Mar 29, 2017 at 4:43 PM, Marc notifications@github.com wrote:

About point 1): sections don't necessarily represent a level of inheritance, but can be used as such indeed, which was my point in Separation of Concerns :) Then you can have any number of them, depending on where you specialize the control.

About point 2): the value type should not be complex. I mostly see it as a Variant, kind of. The property editor doesn't need to know all of them in advance, which is a blessing because it simplifies a lot the implementation. Then you would have a mapper that generates the appropriate view/control with some common functionality depending on what value it is. It could be the same for keys but in a way simpler manner.

The Blender example shows a variant: it is primarily a folding container, where each fold contains a list of arbitrary controls. That's really different from the tree approach which is more generic, but the two are not necessarily incompatible (and can even be combined). In Unity this approach is done using procedural composition (calling some layout functions one by one) rather than having a predefined structure everything should follow, however not sure if that fits Godot way of GUI-ing.

Also generally speaking, don't forget that the property editor stays a property editor. If something is too specific/complex/particular to be edited in there, then the viewport docks can be used too for complete freedom widgets (TileSet tile picker, shader editor etc).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/8196#issuecomment-290202957, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z288PiwE4uwsnNJur6VqzUjJuilDtks5rqrRNgaJpZM4MtGoM .

[toger5]

@Zylann the approach of just providing the variant variable and generate the ui based on that makes a lot of sense. What i mean with complex is, that it needs to be displayed differently for each varient type. So it has to have multiple appearances.

@reduz this means you are not planning to move to a new system? I think it would have big advantages, more people could understand the code faster and a specific class for that perpus also would allow for a more flexible setup juzt a tree might be simple but it is also a little limited in its default functionality. Since the property editor is so central to the editor user it makes a big differnece if it is really good and every ui elemet is adapted to the its usecase. Even i would already have saved a lot of time using godot when the vector ui would be similar to the one blender provides.

[reduz]

@toger5 Sorry, but I believe Blender UI is a mess and not a good example. Godot has hundreds of editable objects, so wrting a specific UI for each of them is a crazy idea. Definitely not willing to go this way.

What might happen at some point is replacing the tree for something a bit more flexible, in order to have more custom widgets for very specific use cases, yet I think it's not high priority.

[eon-s]

Collapsible sections as a first step could be nice.

[toger5]

@reduz okay this is a good point. It would be a tremendous amount of work to make the layout for each section by hand. So this idea was not really thought through. I agree it is lower priority than other parts but it is still something which would have an effect on the user. As I mentioned before the Inspector is used A LOT. So you are more thinking about a table like control which allows for multiple cell types based on on variant types. and it also provides an easy way for collapsing different sections.

@eon-s I actually started on the section collapsing. but it felt like making something hacky even more hacky thats why I stopped and started thinking about another way of making the Inspector. My approach was to add a property to each row, Item of the tree: collapsable. If it is set to true it has the collapsing arrow if it is set to false it doesn't. that allows to turn on collapsing for the whole tree but still only having the collapse arrow at each section.

@reduz do you have any idea how vectors could be implemented with a multiple line UI in the current tree approach? That combined with the collapsing and maybe some slight changes to some input ui elements already would come pretty close to what I was Imagining.

[CharlesWoodhill]

i only did/do c++, so it may be a "developer only" view of things:

1. buttons next to the search_property a. important/most used first: since i for example prefer having properties like position/rotation/scale always at the top for spatials and never need the matrix (could be on bottom somewhere). b. category / classbased view (current implementation) c. alphabetical list, i think it would be more beginner friendly than the search box, since u dont know what to search for :), and its more intuitive if u dont know what props a geometry or spatial or... has.

2. provide some sort of base class "property_editor" derived from control, one could derive from to implement an own editor if wanted, base shouldnt be popup (like CustomPropertyEditor). one could define it in _bind_methods for a prop, maybe as parm for ADD_PROPERTY() and/or define it as default editor for a variant. for example MyBetterColorPicker() :) in a plugin or eventually in godot options it coulc be set as default or its only activated for special properties within the plugin. also the existing editors should/could use them, so one has neat examples one can look into, when making his own :)

3. indexed properties (maybe exist, since i saw some method but havent had time for it :) ) as soon as an property is an PoolArray it should get a row with add/remove and settable itemCount below, or if tree containing, all the elements. example: a terrain can have one or more render passes, each pass one or more textures, but this maybe is better done in a plugin or implemented as nodes... as i did.

[toger5]

@reduz mentioned to maybe tackle this for 3.1 should we add it to the milestone?

[kerskuchen]

Is or could there be a way to just let users create their own property editors for the inspector (like they can with plugins). I've seen this done in Unity very successfully and mentioned it in #11173. I think it would at least solve some of the issues mentioned here. Though sliders and one-click vector fields would be immensely helpful. 😄

[mysticfall]

I was about to create a tracker for a similar concern but I found this issue just before submitting my own. So, I'll just paste what I've written so far here:

---

Currently, you can override how exported properties are handled using Object.GetPropertyList / Get / Set (which at the moment does not work in C#, however - see: #17233). But it has many limitations, such as it only works for the specific node for which those methods are overriden, or that it only supports a few predefined UI types.

It can be seen especially problematic for those who are moving from Unity, as it supports quite a wide range of customization opportunities for such properties.

So, I'll create a tracker here to list a few missing features in that regard.

Support for custom structs or classes with basic type properties

Suppose you created a struct Range(float min, float max) to specify how much the camera can rotate in a certain axis and used it like this:

public Range YawRange { get; set; }

Even though Godot supports float type properties in its inspector view, it wouldn't recognize such a custom struct as Range that holds multiple float type properties. So you'll need to resort to something like this:

public bool YawRange
{
    get => new Range(_minYaw, _maxYaw);
    set
    {
        _minYaw = value.Min;
        _maxYaw = value.Max;
    }
}

[Export] private float _minYaw;
[Export] private float _maxYaw;

It's already quite a lot of code and it'd multiply if we are to add PitchRange and RollRange too.

It'd be better if Godot recognizes such a type which only has primitive or other marshallable (i.e. Vector3) properties and represents it as a property group automatically.

Ability to nest such types would be nice, as it is supported in Unity, but I guess it'd still be very useful even without it.

Custom property converter which can be used on per type, and per property basis

Currently, I'm using Rx with C# and I found a recurring pattern in my code:

[Export]
public bool Active
{
    get => _active.Value;
    set => _active.Value = value;
}

private readonly IReactiveProperty<bool> _active = new ReactiveProperty<bool>(true);

As bool itself (or any other types that Godot supports already) can be edited from the inspector, all I need to do to make IReactiveProperty<bool> work in Godot is to write a wrapper getter/setter methods like shown above.

However, when there are many such properties in a node, or in many different nodes, it can be quite tedious and it'd make the code more verbose.

Overriding Object.GetPropertyList / Get / Set wouldn't help because it's also limited to the specific node in which it is applied.

If Godot provides an interface which we can extend to write a custom property converter for IReactiveProperty<bool>, it'd be much easier to handle such scenarios, for instance:

public interface IPropertyConverter<T>
{
    T GetValue(PropertyInfo property);

    T GetValue(FieldInfo property);

    void SetValue(PropertyInfo property, T value);

    void SetValue(FieldInfo property, T value);
}

Then we can either register it globally, or assign it to a specific property like this:

PropertyConverters.Register<IReactiveProperty<bool>, MyReactiveBoolPropertyConverter>();

// or

[Export(converter: typeof(MyReactiveBoolPropertyConverter))]
public IReactiveProperty<bool> Active { get; set; }

Support for custom property editor GUI

Sometimes, it's needed to use a dedicated GUI for editing a complex property. I'll leave out the details as it seems it's already been discussed sufficiently in this thread.

[MarcusElg]

Will it be possible to create a custom inspector in 3.1? It would be great for tools to be able to do stuff such as: depending on the value of a toggle/checkbox different options are shown. I come from Unity and think that their system works great. Being able to manually add every field for a custom inspector and change it every time the gui updates. I'm very new to Godot so could you explain what the plans for custom inspectors are? Are they even coming to 3.1? Or is this already a thing that I have missed?

[NathanLovato]

@MCrafterzz Juan implemented the new Inspector last week and yes, now it supports inspector plugins https://godotengine.org/article/godot-gets-new-inspector

[MarcusElg]

Awsome! Are there any documentation on it or do I have to wait until the alpha? It would be nice to see how it worked and how a inspector plugin can be created.

[NathanLovato]

The inspector is still getting some work at the moment, best wait until alpha. If you have enough programming experience you can look at the source code, or compile Godot and look at the... should be InspectorPlugin class?

[NathanLovato]

But now the inspector uses regular control nodes so I'd bet you can create any UI in the editor, as a scene, like you would for your game or add-ons and register it in the inspector. That's how other editor plugins work.

[akien-mga]

Closing as fixed by the EditorInspector rewrite.