I think there’s a misunderstanding. I’m not saying that NodeCanvas should mess with the Unity attribute drawers, nor that they should converge on a single implementation of drawers. Drawers (both Unity’s and NodeCanvas’) are simply “attached” to attributes using C# reflection, but, from the a class-design perspective, attributes and drawers totally are unrelated. When Unity finds an attribute that derives from UnityEngine.PropertyAttribute, it looks for a Unity custom drawer attached to that using the UnityEditor.CustomPropertyDrawer attribute: if it finds a drawer it’s used, otherwise it’s not a problem and a default drawer is used. NodeCanvas does exactly the same, the only differences being that it checks if the attribute derives from ParadoxNotion.Design.CustomDrawerAttribute and that it looks for drawer classes derived from ParadoxNotion.Design.CustomDrawer. What would happen if UnityEngine.PropertyAttribute and ParadoxNotion.Design.CustomDrawerAttribute were the same class? Absolutely nothing. Both systems will still work and they would still both have all freedom to evolve in parallel without one interfering with each other, since the mechanism to find custom drawers are totally distinct. What changes for the end-user is that he/she can now have both drawer, a thing that was not possible before.
Login
Register
By registering on this website you agree to our Privacy Policy.