Decoupling GUI and Logic in Editor windows and a Custom Undo/Redo system.

Unity Engine
1

I was searching for a way to decouple the editor window GUI from the logic in it. I also wanted to incorporate the built in Unity serialization for data persistence in the editor window after pressing play/some other assembly reload.

During my search I tried different approaches. I wanted to build modular components I could plug into the editor window, each component representing an action taken in the editor window. It was clear to me that the logic and visual implementations of the action would have to be separate.

At first I tried having 3 different classes: one for the logic, a second for the visual representation and a third as the “glue”/controller between them. Having the glue/controller know what are it’s corresponding visual and logic related classes. Sort of an MVC…but problems arose:

Unity doesn’t serialize delegates/events
I had a problem linking any events from the visual side/class to other parts because Unity doesn’t serialize delegates/events and this information is lost after an assembly reload. So for example the click of a button in the editor window would stop being connected after I pressed play in the editor (the delegate/event invocation list would be empty).

Unity doesn’t serialize System.Type
Looking for a solution I thought I could use reflection instead of delegates/events to connect between say: a button click on the visual side to the controller/”glue”, but again as I found out, Unity doesn’t serialize “System.Type” either – so the whole idea of reflection went flying out of the window.

Finally I decided to use only 2 classes (the logic and the visual side) of an action and rely on generics. So first I would create the logic class and then create a visual representation in the form of a visual class (One thing to remember is that Unity has a problem serializing generics…So you need to have specific implementation of generic classes in order to serialize them – This mean you need to serialize a derived class of the generic class).

In the process I was also trying to implement my own Undo/Redo system for actions taken in the editor window. Here is a short video of what I came up with:

I am making this available to the community at my github repository.
It’s a fully working project but it also still a work in progress:

I haven’t implemented persistence for the system if the window is closed/Editor layout reset. I am guessing it would have to be done using an asset or using a custom serialization method.

Feel free to download or use what you need.
This project is highly documented in code with a separate “How to use” guide as well.
Any comments/questions and suggestions are welcome.

Nims

2

I… Re-read that a few times, and still cannot understand what you wanted to do. Sounds like horrible over-design to me.

As for serializing Type, you can serialize the Assembly qualified name as string and retrieve the type with it.

3

My final aim was to have collection (not in the programing sense) of actions - which I could plug into custom editor windows and have an Undo system for the actions. I needed to be able to serialize the actions. As each action is actually an instance I saw no point in having the logic of the action and the graphical input of the action incorporated in the same class. I had to be able to display the GUI of the actions independently of the instances (logic part of the action) created for serialization (for the undo/redo system). But as i mentioned connecting the 2 together was the problem.

This would mean I would have to do the serializing myself and not relay on the unity serialization. While I can see how I can serialize this data just as the editor is going into Play mode by hooking into EditorApplication.playmodeStateChanged delegate, I cannot see how I would know when to deserialize it - due to the fact that just after the editor enters Play mode I will loose that hook - and will not have away to monitor the changes in Play mode anymore.

PS…I am glad someone bothered reading through!