Custom extension support for EditorExtension

[Container-Zero]

Hello, I’ve been using EditorAttributes for about two years now, and the experience has always been excellent. Recently, however, I’ve been thinking about a few things:

The way EditorAttributes provides Group
[https://editorattributesdocs.readthedocs.io/en/latest/Attributes/GroupingAttributes/foldoutgroup.html]
seems somewhat verbose—it requires declaring an “irrelevant” field and modifying the attributes of every affected field in order to achieve grouping. Other editor tools only require [Group("A/B")], which feels much more concise:

[Group("Settings/Audio")]
public float volume;

I noticed that this is because most of EditorAttributes’ functionality is implemented in PropertyDrawer rather than UnityEditor.Editor. Since PropertyDrawer lacks a “global view” and cannot be aware of other fields during drawing, Group has to work in this somewhat cumbersome way.

Based on this, I’d like to ask:

1. Was this a trade-off made for architectural consistency? If I wanted to implement a [Group("A/B")]-style path syntax, what non-intrusive extension approach would you most recommend?

2. I noticed that you already provide inheritance support in EditorExtension, but if I inherit from EditorExtension and also use [CustomEditor(typeof(Object), true)], it will conflict with the parent class declaration, and Unity’s selection becomes non-deterministic. I also don’t want to use [CustomEditor(typeof(MonoBehaviour), true)], nor do I want to create a base class for all scripts and point CustomEditor to it, as that would bloat the project.

3. With that in mind, I came up with a potentially viable approach:

   • Define an interface (e.g. IInspectorExtension)
   • Maintain a registry
   • Have EditorExtension query and invoke registered extensions in CreateInspectorGUI
   • Let developers implement the interface themselves to extend whatever functionality they want

By extending only two files and adding just a few lines of code to EditorExtension, developers could then customize any UnityEditor.Editor functionality they want in the future, add it into EditorExtension in a non-intrusive way, and automatically benefit from [CustomEditor(typeof(Object), true)] as well as all the features provided by EditorAttributes. Rough example code below:

// ==================== 1. Define Interface ====================
public interface IEditorExtensionProvider
{
    /// <summary>
    /// Returns custom Inspector UI, or null to use default rendering
    /// </summary>
    VisualElement CreateInspectorGUI(EditorExtension editor);
}

// ==================== 2. Registry ====================
public static class EditorExtensionRegistry
{
    private static readonly Dictionary<Type, IEditorExtensionProvider> _providers = new();

    public static void Register<T>(IEditorExtensionProvider provider) => _providers[typeof(T)] = provider;
    
    public static IEditorExtensionProvider Get(Type type) => 
        _providers.TryGetValue(type, out var p) ? p : null;
}

// ==================== 3. EditorExtension (only a few lines added) ====================
[CanEditMultipleObjects, CustomEditor(typeof(Object), true)]
public class EditorExtension : UnityEditor.Editor
{
    public override VisualElement CreateInspectorGUI()
    {
        // >>> NEW: Check for custom Provider <<<
        var provider = EditorExtensionRegistry.Get(target.GetType());
        if (provider != null)
        {
            var customUI = provider.CreateInspectorGUI(this);
            if (customUI != null) return customUI;
        }
        
        // Original logic...
        return DrawDefaultInspector();
    }
    
    // Expose helper methods for Provider to use
    public VisualElement DrawNonSerializedMembers() { /* ... */ }
    public VisualElement DrawButtons() { /* ... */ }
}

// ==================== 4. User Implementation Example ====================
public class MyCustomProvider : IEditorExtensionProvider
{
    [InitializeOnLoadMethod]
    static void Register() => EditorExtensionRegistry.Register<MyComponent>(new MyCustomProvider());

    public VisualElement CreateInspectorGUI(EditorExtension editor)
    {
        var root = new VisualElement();
        
        // Custom grouping logic...
        root.Add(new Label("My Custom Group"));
        
        // Reuse EditorExtension functionality
        root.Add(editor.DrawButtons());
        
        return root;
    }
}

What do you think about this approach? The above is just a question and a suggestion, and my understanding may be somewhat one-sided—please excuse any shortcomings.

[v0lt13]

Was this a trade-off made for architectural consistency?

Originally I didn't exactly know how other packages handled groups like this and I am trying to avoid having to rewrite the entire inspector and completely change the workflow of creating editor windows so I came up with this workaround which kinda forces you to region your variables rather then placing group attributes all over your script, and also centralizes the options of the group (like labels, drawInBox) in one place.

For example here is a SO script of mine:

	[CreateAssetMenu(fileName = "PlayerControllerOptions", menuName = "Player Controller Options")]
	public class PlayerControllerOptions : ScriptableObject
	{
		[FoldoutGroup("Physics", nameof(GravityScale), nameof(TerminalVelocity))]
		[SerializeField] private Void physicsFoldout;

		[field: SerializeField, HideProperty] public float GravityScale { get; private set; }
		[field: SerializeField, HideProperty] public float TerminalVelocity { get; private set; }

		[FoldoutGroup("Movement", nameof(DefaultPlayerSpeed), nameof(SprintSpeedMultiplier), nameof(JumpForce), nameof(MaxStepHeight), nameof(MaxSlopeAngle))]
		[SerializeField] private Void movementFoldout;

		[field: SerializeField, HideProperty] public GameplayValue DefaultPlayerSpeed { get; private set; }
		[field: SerializeField, HideProperty] public GameplayValue SprintSpeedMultiplier { get; private set; }
		[field: SerializeField, HideProperty] public GameplayValue JumpForce { get; private set; }
		[field: SerializeField, HideProperty] public float MaxStepHeight { get; private set; }
		[field: SerializeField, HideProperty, Clamp(0f, 180f)] public float MaxSlopeAngle { get; private set; }

		[FoldoutGroup("GroundCheck", nameof(GroundCheckRadius), nameof(GroundCheckOffset), nameof(GroundMask))]
		[SerializeField] private Void groundCheckFoldout;

		[field: SerializeField, HideProperty] public float GroundCheckRadius { get; private set; }
		[field: SerializeField, HideProperty] public Vector3 GroundCheckOffset { get; private set; }
		[field: SerializeField, HideProperty] public LayerMask GroundMask { get; private set; }

		[field: SerializeField, ToggleGroup("Wall Climbing", nameof(DefaultClimbSpeed), nameof(WallClimbRotationSpeed), nameof(WallJumpForce), nameof(WallCheckDistance), nameof(WallCheckOffset), nameof(ClimbableTag))]
		public bool CanWallClimb { get; private set; }

		[field: SerializeField, HideProperty] public GameplayValue DefaultClimbSpeed { get; private set; }
		[field: SerializeField, HideProperty] public float WallClimbRotationSpeed { get; private set; }
		[field: SerializeField, HideProperty] public float WallJumpForce { get; private set; }
		[field: SerializeField, HideProperty] public float WallCheckDistance { get; private set; }
		[field: SerializeField, HideProperty] public Vector3 WallCheckOffset { get; private set; }
		[field: SerializeField, HideProperty, TagDropdown] public string ClimbableTag { get; private set; }

		[field: SerializeField, ToggleGroup("Flying", nameof(FlyingMode), nameof(DefaultFlightSpeed), nameof(FlyingForce), nameof(GlideVerticalSpeed), nameof(GlideRotationSpeed))]
		public bool CanFly { get; private set; }

		[field: SerializeField, HideProperty] public FlyMode FlyingMode { get; private set; }
		[field: SerializeField, HideProperty] public GameplayValue DefaultFlightSpeed { get; private set; }
		[field: SerializeField, HideProperty] public float FlyingForce { get; private set; }

		[field: SerializeField, HideProperty, ShowField(nameof(FlyingMode), FlyMode.Glide)]
		public float GlideVerticalSpeed { get; private set; }

		[field: SerializeField, HideProperty, ShowField(nameof(FlyingMode), FlyMode.Glide)]
		public float GlideRotationSpeed { get; private set; }

		[field: SerializeField, ToggleGroup("Swimming", nameof(DefaultSwimSpeed), nameof(SwimForce), nameof(SwimRotationSpeed), nameof(WaterCheckRadius), nameof(UnderwaterCheckRadius), nameof(WaterCheckOffset), nameof(UnderwaterCheckOffset), nameof(CanSink))]
		public bool CanSwim { get; private set; }

		[field: SerializeField, HideProperty] public GameplayValue DefaultSwimSpeed { get; private set; }
		[field: SerializeField, HideProperty] public float SwimForce { get; private set; }
		[field: SerializeField, HideProperty] public float SwimRotationSpeed { get; private set; }
		[field: SerializeField, HideProperty] public float WaterCheckRadius { get; private set; }
		[field: SerializeField, HideProperty] public float UnderwaterCheckRadius { get; private set; }
		[field: SerializeField, HideProperty] public Vector3 WaterCheckOffset { get; private set; }
		[field: SerializeField, HideProperty] public Vector3 UnderwaterCheckOffset { get; private set; }
		[field: SerializeField, HideProperty] public bool CanSink { get; private set; }
	}

And I just got used to it, no one complained it was all good and dandy.

Right now I think is too late to change it without breaking everything (unless people don't get annoyed), but if I were to change it I think I would still use the property drawer.

I would have the current group attributes act the same as they do right now, but instead of referencing the properties in the group attribute I would add a group ID parameter and a new attribute called GroupProperty or something like that, which takes in a group ID and also hides the original field so you don't have to spam the HideProperty attribute.

Then the root group will just look for all properties with the GroupProperty Attribute filter them by the Id inputted and draw those properties inside the group.

On the root you can also have the option to draw the attached property if you want to start with a variable and don't want to use a holder.

Your idea for the EditorExtension is good, but I am trying to avoid having to change the workflow of creating editors. If you want to create your custom editor that overrides all object editors there is nothing wrong with just commenting or removing the CustomEditor line and adding it to yours while still inheriting.

[Container-Zero]

Hi, thank you for explaining the design process behind Group.
I completely understand and agree with your point of view — and I also agree that it would not be a good idea to forcefully change the current workflow of FoldoutGroup.

For example:

1. A full refactor would be very difficult and would likely require introducing a more UnityEditor.Editor-driven architecture, which would not match the current design philosophy of EditorAttributes.
2. It would create compatibility issues for existing users who already rely on the current grouping system.
3. Even introducing a second “alternative” grouping API could be confusing, since it would result in two different ways to achieve the same inspector behavior.

So overall, I fully understand why changing the current approach is not desirable.

---

That said, the main point I wanted to share is slightly different:

I believe adding a lightweight interface-based extension point to EditorExtension could be beneficial.

This would not change the existing architecture or workflow — it would simply allow users to optionally hook into CreateInspectorGUI in a non-intrusive way, if they need additional functionality.

I think this could be valuable for a few reasons:

1. Minimal code, zero architectural disruption
   Adding an interface/provider mechanism requires only a few lines in EditorExtension, without affecting existing behavior.
2. Improves long-term extensibility
   Since you are the main maintainer of the project, having an official extension point could increase the general usability of EditorAttributes for future contributors and advanced users.
3. Inheritance-based extension can be awkward at scale
   Right now, the main way to extend UnityEditor.Editor behavior is through inheritance, which works, but introduces some practical issues:
   • Each derived editor needs to override methods like CreateInspectorGUI, and it is easy to accidentally forget to call the default rendering logic (buttons, non-serialized members, etc.).
   • To apply an extension globally, the only remaining scope is something like [CustomEditor(typeof(MonoBehaviour), true)], unless the user removes or replaces the existing [CustomEditor(typeof(Object), true)].
   • As more features are added, a single inherited editor class can quickly become bloated.
   • Interfaces provide a clean way to decouple features into independent modules while still working under the same global scope.
   • If a feature is not needed, it can simply be removed by deleting the provider implementation, similar to how PropertyDrawer-based features work.
4. Keeps EditorAttributes non-intrusive
   EditorAttributes itself would not need to implement any additional UnityEditor.Editor logic — it would only expose an extension hook, and developers could implement whatever editor-level customization they want.
5. All upside, no downside (in theory)
   Since the extension mechanism would be purely optional and would not affect existing inspectors unless a provider is registered, it should not introduce breaking changes.

---

Of course, I do not mean any offense — these are just my personal thoughts after working with the framework and thinking about extensibility.

If you agree that this could solve a real pain point, I would be happy to prototype it locally and submit a working PR for your consideration.

Do you think such an interface-based extension point would be acceptable and useful for the project?

[v0lt13]

I will think about it when I start working on the next update

[Container-Zero]

Additionally, I recommend using Scripting Define Symbols as a switch for the CustomEditor.

For example:

#if !EDITORATTRIBUTES_ATTRIBUTES_DISABLED
[CanEditMultipleObjects, CustomEditor(typeof(Object), true)]
#endif
public class EditorExtension : UnityEditor.Editor
{
    ...
}

This ensures that:

1. When users want to disable the scope of the CustomEditor, they can do so in a non-intrusive way (without modifying the EditorExtension script).
2. When users extend functionality via inheritance, they can use typeof(Object) in their own scripts if they wish.
3. The cost is only two lines of code—elegant and clean.
4. Users can temporarily disable the effects of EditorAttributes through settings, without having to completely remove it from the project.
5. It has no impact on existing users; only users who want to disable it need to explicitly add the Scripting Define Symbols.

[v0lt13]

Hmm this is actually a better option then the one before, that way you can override the object inspector without problems and its easier for me to implement.

[Container-Zero]

Yes, this approach is indeed very convenient, and it allows users to fully control the scope of CustomEditor.

That said, from another perspective, I personally feel that if EditorAttributes itself provided an interface-based solution, it could become a more powerful and mature editor extension plugin overall.

As I mentioned earlier, once EditorAttributes is used for Editor extensions rather than PropertyDrawer extensions, its current workflow can become fairly demanding. Users often need to design and maintain their own interface or architectural solutions in order to properly extend and manage editor functionality, which adds a certain amount of overhead.

If EditorAttributes were to natively support this kind of architecture, it would certainly be a wonderful addition.
Of course, if implementing this would require too much of your time or effort, please feel free to disregard the suggestion — I completely understand and truly appreciate the work you’ve already put into the project.

[v0lt13]

The point of EditorAttributes is to simply just being able to customize the editor via attributes without any editor code, there is no intention of EditorAttributes becoming another editor framework, Unity already provides UI Elements and UI Builder which are amazing solutions for custom editors and unless you have some niche usage there is nothing you can't handle with just using those, and EditorAttributes will never get in the way.

While the idea of turning EditorAttributes into a framework is cool but way outside the scope of the project and there are a lot of issues that can arise from it.

But I will keep the idea of disabling EditorExtension if people want to override all Object editors.

[Container-Zero]

Hey! I’ve come up with a solution that could be a win-win.

You would only need to provide a way to control the scope of CustomEditor using Scripting Define Symbols.
On top of that, I would develop an interface-based extension framework, tentatively named EditorAttributes.Extension. This framework would depend on EditorAttributes and build upon it, providing a more flexible and composable set of editor extension capabilities to address the more framework-oriented requirements we discussed earlier.

This approach allows EditorAttributes to remain focused on its core responsibilities, keeping it lightweight and stable, while EditorAttributes.Extension serves as an optional extension for users who need higher levels of customization. It also means you wouldn’t have to maintain enhancement features that may only be useful to a small subset of users.

Since I will be using and maintaining this extension framework in my own projects over the long term, I can also ensure ongoing testing and maintenance to keep it stable and reliable.

If the project turns out well, I plan to release the framework along with the editor enhancement features I implement as an open-source project on GitHub. When that day comes, would you be open to briefly mentioning this optional extension in the README? 😄

[v0lt13]

Sure, that works.