New feature: Editor Views within Editor Contexts

At the SF Unity User Group a few nights ago, one gentleman asked me (as he had in fact once before) whether Strange could be used within the Unity Editor. He wants to do a better job building Editor extensions, and he’d like it if we could assist.


Sure, I said, if you want to build in the necessary changes. I wasn’t too keen to do the work myself…how many people actually have this need? But the more I thought about it, the more I decided it was an appropriate use case…and it didn’t actually seem that hard. We’d mostly just need a specialized Context and a specialized MediationBinder.

So I’ve been whirring away at this for a day or two, and the (definitely not-ready for production) alpha is now on branch feature/editor. It principally involves a new extension package called ‘editor’ that includes the following classes:

  • EditorContext (same as Context, but specialized for Editor)
  • EditorContextException (for reporting errors)
  • EditorMediationBinder (a specialized variation of MediationBinder)
  • EditorMediator (similar to, but with important differences from, Mediator)
  • EditorMVCSContext (a specialized variation of MVCSContext)
  • EditorView (like View, but we extend EditorWindow instead of MonoBehaviour)

Please review the code. For the most part, there’s not a lot that’s surprising. But we do have some differences to discuss, which I’ll get to after I (finally) get to our actual headline.

In order to test my work, I’ve started working on a StrangeIoC inspector. The beginning of this is also on the branch. Thing is, I don’t do a lot of Editor extension work, so I’m not entirely sure how to proceed. And any way, what features would be most useful? So I’m going to start working on this tool-thingy as part of the next release, but I’ll probably come to you via this blog to generate ideas and help me fix the things I break.

OK? Ball’s in your court my friends.

Moving on, here are some things you probably want to know about the differences between regular Strange and Editor-extending Strange.

There’s a lot more working around statics

EditorWindow features seem to be built on a lot of static methods. This isn’t helpful in a Strange world. On the other hand, Strange can help isolate a lot of this silliness. For example, my StrangePanel already has a ScriptReloadService to isolate the service aspect of knowing that scripts have been updated. This helps with abstraction and keeps my StrangePanelView focused on View-related behavior.

There’s no ContextView

Traditionally, we kick off a Strange app with a MonoBehaviour at the top of a view hierarchy. This doesn’t make sense in Editorland (the most magical place on Earth), where we instead use the [InitializeOnLoad] attribute. What’s nice about this, though, is that [InitializeOnLoad] means our package is just plain up-and-running when we enter Unity. And there’s no need to track or think about which View is “on top”.

There’s no Cross-Context behavior

At least for V1, this seems OK to me. It’s a bit hard to say at this point whether we want multiple contexts in a single Editor extension. I suppose we might. Anyway, let’s cross that context when we come to it.

To be clear, I’m talking about multiple Contexts in a single extension. I’ve made sure to handle the possibility of more than one extension, both of which happen to use Strange (this is called ‘optimism’). Each extension gets it’s own Context within which to operate.

EditorMediators are not Views

In regular Strange, your Mediators are MonoBehaviours, so in some respects they’re just like Views. I’m not even sure I could make this happen in Editor-flavored Strange, but I really didn’t try. EditorMediators now actually behave much more like Mediators in Robotlegs, in that they are in contact with the View, but unable to perform actual View logic themselves. This doesn’t seem like a problem to me. You’ll have to let me know if you disagree.

For the EditorMVCSContext, Signals are the primary event bus

I’ve been thinking about doing this in the rest of Strange, where the primary event bus is still EventDispatcher. For Editor, this seems an obvious thing to do, since Signals really are a better approach, and we may as well hit this brave new world with the best tools.

Review and Comment

As always, I ask you to look at this now, before it’s a fait accompli and in the live product. It’s better for everyone if this work is challenged and vetted a lot before we use it in anger.

And let me know what you want/need in a Strange Inspector. Should we be able to inspect our bindings from there? Write them? List all our Contexts/ContextViews? Give me some ideas!


2 thoughts on “New feature: Editor Views within Editor Contexts

  1. Pingback: Owning my responsibilities | StrangeIoC

  2. I’d like to help but modifying the Strange codebase itself is way out of my league. It’s been a while since I last tried StrangeIoC so I don’t even know where to start.

    I’d really want to use this because I’m making a pretty hefty editor script right now, it’s a map editor for our game:

    One thing I was hoping was support for the Editor class (the one that lets you customize the Inspector for a MonoBehaviour script). The reason I use that is because it lets you draw on the scene window itself (in the screenshot link above, the leftmost panel is a custom GUI drawn by the Editor script I made).

    Ultimately, I’d want my map editor to be usable not only within the Unity Editor, but also in-game as a built-in mod tool to let players create their own maps. That’s another reason I want to use StrangeIoC for it.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s