Scripting EditorGUI.[Begin/End]DisabledGroup deprecation?

As mentioned in the change log:

Now, is there really any good reason to deprecate them? They work perfectly fine and, to me, actually look cleaner. The way EditorGUI.DisabledScope works is a exploitative misuse of the Disposable pattern, and I can't understand how is it better in any way. I am already scoping my code just fine like this:

Code (CSharp):

1. EditorGUI.BeginDisabledGroup(isAvailable);
2. {
3.  
4. }
5. EditorGUI.EndDisabledGroup();
6.  

Besides, does it even work as it should in JavaScript and Boo? AFAIK, they don't have a using keyword in the context of Disposable. I guess you could still call the Dispose method, but that makes the whole construct really ugly.

If I'd really want to make something like EditorGUI.DisableScope, I'd write it myself in just a few lines:

Code (CSharp):

1. public class GUIDisabledScope : IDisposable {
2.     public GUIDisabledScope(bool disabled) {
3.         EditorGUI.BeginDisabledGroup(disabled);
4.     }
5.  
6.     public void Dispose() {
7.         EditorGUI.EndDisabledGroup();
8.     }
9. }
10.  

I'm not against new methods if someone finds them convenient. But please, do not deprecate something that works perfectly if the replacement doesn't provides any actual improvement.

 

I would like to simply add that this new pattern will not reduce the number of lines that we use in our code. In order to retain readability in complex UI scenarios, we'll still end up with the following:

Code (CSharp):

1. using (new EditorGUI.DisabledScope(bDisabled))
2. {
3.  
4. }
5. // End DisabledScope

This wouldn't save us any lines or improve readability.

If it wasn't already clear, we naturally adopted the same exact scoping setup that @ZimM outlined above (we do this for all Begin/End setups - Horizontal/Vertical/etc.).

Does this change perhaps include special fixes for memory usage or performance otherwise? Are there also plans to deprecate the EditorGUILayout classes as well? (I see that there are similar "Scope" versions of those available now, too.)

 

This will break a lot of editor extensions in the asset store...

 

Well, it's only "deprecated" - so rather than breaking outright it will just spam everyone's console with lots of warnings...

 

Until Unity 5.5 or something, when it will break a lot of editor extensions...

 

Cool, thanks! I appreciate the urge to keep the APIs moving forward but the increased release rate of Unity these days has put increased pressure on us Asset developers. Unity seems to currently maintain two released versions of Unity at a time and then a beta (and alpha). The nice thing for Unity is that this stuff is all internally consistent with each release. Unfortunately, Asset developers currently have to jump through hoops to provide scripts (and especially DLLs) that work across versions of Unity (as developers use a large variety of different versions). Unfortunately, a small change like this can have a significant impact on Asset development maintenance and upkeep.

Thank you very much for the response!

One quick followup question: how are folks supposed to use the DisabledScope API with UnityScript or Boo? As pointed out by @ZimM, those languages don't have the using keyword...

 

I take it this will make it into the documentation? That seems like a mistake that's very easy to make. A big loud warning would be real nice to see

 

I accepted the task to make the changes.
But I noticed that I like the way the code looks with this better.
My reasoning is, the new format exploits existing code errors to help us avoid ending the DisabledScope. The old way leaves open a possible "working" error that may or may not trigger a useful error.
It would be good to leave the old way without decrements until an auto fix can be applied for it.

 

There are a lot of extensions (assets in the Asset Store, for instance) that are compiled into DLLs. Those frequently contain this code. Unless the DLLs were updated to handle this I would really prefer to not to see it deprecated. At least not until the next major API change (like 5.x → 6.x). Doing the deprecation simply means that users would end up getting warning spam all the time that they could do nothing about :/

It's a tricky problem, for sure, and if this is truly the wave of the future, then it would make sense to set the deprecated flag at some point. But slowly deprecating single APIs like this mean lots of complication to provide DLLs across Unity versions. If a sea-change of APIs are coming, I'd rather see them come all at once than trickle out over several versions

 

How can an autofix possibly be added? some developers have created their own utility methods that combine disabled group logic within their own BeginSection and EndSection type methods.

 

I hadn't considered scenarios where users would wrap those in their own utility methods. That's an excellent point.

I guess this is one of those things that you just leave to the users at a major "API Update" phase.