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:
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:
public class GUIDisabledScope : IDisposable {
public GUIDisabledScope(bool disabled) {
EditorGUI.BeginDisabledGroup(disabled);
}
public void Dispose() {
EditorGUI.EndDisabledGroup();
}
}
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:
using (new EditorGUI.DisabledScope(bDisabled))
{
}
// 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_1 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.)
Hello guys. We are looking at this. We definitely don’t want nor plan to break anyone’s package, don’t worry
The change was introduced because we thought it would make sense to have an API that guarantees scopes to be ended properly and “automatically”. Also, we wanted to make DisabledGroupScope a struct instead of a class, to avoid GC allocations which can impact a lot complex UIs; but unfortunately a class->struct change will break precompiled plugins so we are require to introduce a new API anyway and keep backward compatibility.
Deprecating the old API was done because it is the practice we usually follow these days, that said, all the discussion above makes sense, and we are probably going to remove the deprecation warning and leave the API there as it was. And introduce the new one for the people who care/need to save a useless allocation.
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_1 , those languages don’t have the using keyword…
DisabledScope implements IDisposable, so UnityScript/Boo users can invoke the .Dispose method directly. It makes using this API on US/Boo very similar to using the old one, but it still saves you a useless allocation.
I accepted the task to make the changes:(.
But I noticed that I like the way the code looks with this better:roll_eyes:.
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:sunglasses: until an auto fix can be applied for it:eyes:.
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.
that I like the way the code looks with this better:roll_eyes:.
