Add Editor Setting to disable large Arrays/Dictionaries being split into Pages

[Arecher]

Describe the project you are working on

Game Project

Describe the problem or limitation you are having in your project

Any exported array with more than 10 entries is automatically split into multiple pages. The pages aren't all that clearly indicated, which often leads me to forget about them. Especially while working with arrays with sizes of 11 or 12, I tend to forget to check the next page. Pages also make it more work to add resources to an array/dictionary, since it requires additional clicks to switch page.

I would like a setting to disable the creation of pages on exported Arrays/Dictionaries

Describe the feature / enhancement and how it helps to overcome the problem or limitation

An editor setting in Editor Settings > Interface > Inspector which allows disabling the pages, and instead lists the entire array/dictionary as one long list. The Inspector can already be scrolled, so that shouldn't be a large issue.

Alternatively, if this is deemed a bad idea in case someone makes an extremely long array and exports it: Add a similar setting that allows us to set the Entries per Page. If I can make the amount of entries per page 50 or so, that'll fix any issues I'm having as well.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

See above

If this enhancement will not be used often, can it be worked around with a few lines of script?

Can be worked around by using the Page-system. I think most developers would like to see more than 10 entries per page, if not all entries, by default.

Is there a reason why this should be core and not an add-on in the asset library?

Core: Setting for a Core feature's UI

[Calinou]

I think it would be better to increase the number of items per page to 100-200 and leave it there. The editor may break if there's no limit, but 100-200 should be fine. Still, it needs to be tested with complex resources in each array item.

[Zireael07]

Alternately, make the page counter pop (bold or some other style tweak)

[Calinou]

I've done some testing with a string array of 600 items, and increasing the number of items per page to 500 makes selecting the node in the inspector very slow (taking 1+ second on an i7-6700K).

With 100 items per page, it's not as bad but I expect it to be quite slow on low-end machines still. This will be worse with resource arrays since their inspectors are much more complex. (This was tested on 3.2.x.)

Let's settle with 50 items per page for now and see how it works 🙂
It's still a 5× improvement over the current value.

[Arecher]

Thank you for all the effort and testing. 👍
A size of 50 seems a lot more manageable, and should be more than enough for most basic usage.

If it turns out 50 leads to noticeable loading times for nodes, it might be worth making the default 10-20, and allowing that number to be set (up to a max) in an editor setting after all.