Thank you - Arrays and lists in the inspector can be reorderable now

From a13 release notes:

• Editor: Arrays and lists in the inspector can be reorderable now. Use [Reorderable] attribute on your script variables to turn this on.

Just thank you.

 

Seems strange to require an attribute to make list reorderable. Why not make every list always reorderable? Is there a single valid use case for having non-reorderable list?

 

@Aras argues it's too aggressive a change to make default.
https://twitter.com/LegoCylon/status/1268429416192827393

 

Having implemented reorderable arrays and lists myself (nothing fancy, just the ReorderableList stuff present in Unity), the cost of rendering a reorderable list or array is greater than drawing a regular array. Thus, even if their implementation might very well be more efficient than mine, if you don't need reorder, you're paying for something you don't use, which is really sad imo.
I think it is nice that this is an attribute. Maybe the other way around could have been better (attribute to turn reorder off), but as stated above, this is kind of a big change.

 

Here's a crazy idea that will take years to implement at the rate that things are going: A preference.

 

Eh, a preference would mean that you need 2 attributes of which one is always useless.

 

We have two input systems, one of which is only there for backwards compatibility now. We have three graphics pipelines, two of which no one asked for. We have two programming stacks, one of which benefits a minority of projects and has been in full-time development for 4 years with no end in sight. We need a `[CustomEditor(typeof(T))]` attribute in addition to inheriting `Editor` while just inheriting a hypothetical `Editor<T>` class would accomplish the same thing and allow users to more cleanly implement custom editors.
I think that attribute redundancy should be the least of our worries right now. Granted, the last example is of attribute redundancy.

As for your objection itself, it's just pick your poison: (non-)Performance by default, or redundancy. Although after testing it myself, I'd be hard pressed to think that this performance impact is noticeable unless you have hundreds of items in your list, at which point the editor has some trouble regardless.

 

But once 2020.2 releases how do you follow up on that? The majority of people probably won't be vocal about whether they prefer this as opt in or opt out.

 

A preference in the settings is perhaps an option?

 

Let's be honest: We're stuck forever with however this releases in 2020.2, since the only type of breaking change that Unity does nowadays is removing features altogether. Minor automatically upgradable breaks like this? Nope.
It has to be decided as a global attributeless change or as a preference before 2020.2 releases. My vote is on the former: With 1000 items, I saw a <1% difference in CPU usage and barely any in performance between reorderable and non-reorderable. I can't think of a use case for serializing a list with over a thousand items anyway. If you have a list that big, the editor will already be crawling even on some high-end computers.

 

I gotta agree with the argument that whatever lands in 2020.2 will stick around. I seriously doubt they will ever justify spending time deprecating this attribute and adding another one. Just imagine the confusion. This should be decided now and in my opinion non-reorderable lists don't make any practical sense. If doesn't break UI layout and doesn't incur any tangible performance cost, go for the "enabled by default" approach and just be done with it.

 

Agreed.

 

I tested it and think that it should be default. If you're worried about performance even though it only starts to differ after a thousand items, micro-optimize and/or remove the animation.

 

It's very usable the way you made it draggable. I don't see any downsides to it
Just make sure there is a way to reset to default order and that the undo is working. ( still have to check if thats already the case )

A global preference would be my preferred way of opting out.
but I can see some people wanting more control.

The new faster enter playmode also has a global preference and in some cases I will turn it off but most of the time its on.

 

Have you thought about making it the default in (some) alpha versions? That way it's forced on alpha testers and would cause drama if people are unhappy or silence if everything is fine.

I'm not interested to add this attribute by hand to hundrets or thousands of fields to give it a real-world test and small scale tests have you done yourself already.

 

In case it is made default, then a "ReorderOption(bool reorderable)" (or NotReorderable, idk) tag would be great. It would allow one to turn on or off the reorderability of the array (in case one absolutely doesn't want an array to be reorderable, you know... designers being designers, us progs sometimes have to be a little bit preventive...).

 

Yes makes sense for me

 

Yes!

 

I just wonder about what reason would someone want non-reorderable arrays/lists. Is the performance difference big enough for people to need to turn it off? If that's the case then perhaps it's better to also let them toggle it on/off for the entire project via the editor settings.

If for some reason I wanted the opposite of the default behavior I definitely wouldn't want to go through each collection and litter the codebase with tags.

 

BTW, thanks for being communicative. It often feels like giving feedback is pointless and that no one is listening. But when developers like you take the extra time to discuss with the community it sure does encourage giving feedback

 

I think it's kind of a security, knowing that we can disable it if we want. Or if we don't want designer reordering stuff around.

 

If the main concern is the layout, that's hardly a show stopper for anyone and I believe it's a fair price to pay for moving forward.

The concern about the assumed order of the list is valid but it was always fragile. If any logic depended on inspector-set list order, it will become only marginally more fragile now.

And as you say, there's always the opt-out in case the underlying issue cannot be fixed.

 

I'd like to ask you (I mean every Unity Developers who is working on the Editor), to utilize the Preferences menu more. There is no need to hardcode these things and no need to put everything in code (and I say this, a coder...).
Please put the default setting in the Preferences and if you feel like it, you can develop the attributes to overwrite the default behavior.

Please, don't be an Apple, be a Blender (here's the tool, you can turn on and off everything, modify it to your heart's content, we don't care).

 

Just wanna drop by and say it's a fantastic change when a Unity developer responsible for a certain feature directly communicates in a forum and even responds to feedback.

I really miss the same level of transparency with the team behind Addressables. The way they have some kind of community/QA guy relay feedback back/forth doesn't seem efficient and valuable user voices are often not heard.

 

Maybe you should train other teams where the communication by the community isn't perceived as good as yours.

 

A reorderable array feels more natural and intuitive in a graphical editor, with drag&drop and all that. Also easier for beginners.
If a dev needs it to not be reorderable, he can use an attribute.

 

A reorderable array feels like a bunch of designers in the team gonna play with it from the inspector and ask why the build is not working anymore
[Reorderable] looks cool from code. I had no idea about it !
Thanks for the tip!

 

As a long-time user of Odin Inspector, it's baffling to me that it's taken this long to get such a basic useful feature implemented. In a time when Unity is desperately in need of leadership and vision regarding the editor, I'm confused as to why Unity hasn't reached out to acquire the Odin Inspector team to quickly usher in more desperately needed QoL improvements like this. Reorderable lists should be old news by now.

 

Exactly. Editor QoL improvements are for me, 100 times more important and hype-inducing than any new ML or graphics package they show off in their presentations. Editor is so painful to work with. Although I love working with Unity compared to other jobs I had in the past, 90% of time I write C# code which is awesome with Unity. But that 10% I have to interact with Editor in some ways and it's just horrible. Insanely long compile and domain reload times, basic features such as searching for dependencies are missing (have to buy/write a lot of basic tools), basic features like Dictionaries and generics serialization are not supported which is just insane considering how many releases we had without any effort from devs to fix it.

I'm happy this is getting finally looked upon but seriously, Editor usability should be #1 priority above everything else! Move some people from other teams to this, change priorities, I don't know, just step up your game, UT!

This is a bad year for Unity (competition almost entirely removed Unity from AA+ game development) and the best way you can fix this is to make developers love working with Unity again.

#MakeUnityGreatAgain

 

Well, even if it is true, they didn't do it with nice UI, that's for sure. Have you even seen the competition?

 

Not sure if it was like this in earlier alphas already, but showing the array size, without having to expand the array first, is extremely useful.

 

I'm seeing a reorderable list on some of my objects, but not all. I'm not using [NonReorderable]. Any idea?

Here is works:


Here it doesn't work:

 

This is a really great change, although I do agree it puts a lot of custom editors in a weird position. If you're drawing the field with a PropertyField or something to make things generic then losing control of whether or not the list is reorderable is not ideal.

In utopia, this change is a no brainer and I'm really happy about it although I do see the caveats of doing this change suddenly. I think the real question becomes whether or not 2020 is the release that is a right time to introduce this sort of thing as a hard change. Personally, I think it would be.

 

Here you go: (Case 1260888) 2020.2: Reorderable list sometimes not shown

EDIT: After sending the bug-report, I found out that it can be reproduced very easily in a new project too.

Code (CSharp):

1. using UnityEngine;
2.  
3. public class Banana : MonoBehaviour
4. {
5.     [SerializeField] Component[] m_Array;
6. }

Shows up as:

 

Here you have another one to look at:
(Case 1260896) 2020.2: Deleting array element shows "Invalid AssetDatabase path" warning

 

Aaaaand another one:
(Case 1260899) 2020.2: DEL key doesn't work to delete array element

 

Ooops, found another one:
(Case 1260904) 2020.2: Array contents don't line up with other UI elements

 

@Aras While you're at it, is there any chance you can add a "Delete" button next to each item?

I've created the following mock-up for you, to show what I mean:


Deleting items from a list is a bit cumbersome at the moment, as you need to right-click an item and choose "Delete Array Element" just to find that it only clears the entry. Then right-click the same item again and choose "Delete Array Element" to actually delete it.

I'm fine with it if you want keep this "need to delete twice to actually delete" for the new delete button, because quickly double-clicking it isn't much of an issue.

 

I just found this one:
(Case 1281321) Reorderable list does not support right/left keys to expand/collapse items

 

(Case 1281324) Reorderable list blue rectangle looks cut off

 

Yes please. We have reorderable lists in our project for ages and a "per-item delete button" was the second thing we added after implementing reorderable lists.

​

 

Selecting a list element and clicking the Minus button doesn't work for deletion?