Package Editor GUI quirks

[levicki]

Is your feature request related to a problem? Please describe.

1. When editing entries in an array such as AutoLevelUpInfo in character class packages, it is useful to have all the child items expanded while editing. However, any change you make to any single StructProperty value inside that array collapses all the children in an array except for the one you just edited.
2. When editing entries in an array such as PowerCustomActionClasses, any change you make to any single ObjectProperty makes the array scroll to the last element.
3. When clicking a down arrow on the first element in an array, the down arrow is pushed to the right and replaced by up arrow so if you click again instead of moving the element further down you will return it to the first position.
4. For StructProperty items clicking down arrow will in addition to moving the item expand it and move selection to its first child entry so you won't be able to keep clicking to move it further down.
5. For arrays such as MappedPowers the button names are way too long and the dropdown box is scaled in such a way to push the set button out of the window right edge: It seems not possible to press Enter key to set the value you entered so having to resize the right window edge until Set button appears is a bit of a drag.

Describe the solution you'd like

• State of array child nodes (expanded or collapsed) and current position in an array should be preserved when values are edited.
• GUI elements should not jump around and swap places.
• If GUI is scalable it should scale in such a way that important things such as Set button do not disappear out of the window.

Describe alternatives you've considered N/A

Additional context N/A

[Mgamerz]

For point 5, the enter listener is on the Index field, since it's a name. Tab over to it and press Enter.

[levicki]

For point 5, the enter listener is on the Index field, since it's a name. Tab over to it and press Enter.

The problem is that when the dropdown edit field and set button are visible, you start editing text by deleting the part of the name after the underscore (say Cloak in the above example).

If you then start typing first letter of the different power name (for example letter S for Stasis), the edit box, index field, and Set button can all disappear because the dropdown edit gets resized to fit the first longer name continuing with letter S (which can incidentally be SentinelMeleePassive, Singularity, etc).

Since you no longer see the dropdown edit field you have no idea what got auto-completed and what you are going to confirm if you hit Tab and Enter after that point. The only workaround is to keep resizing the form and from what I noticed, the form doesn't remember neither size nor the position so you have to do that every time you open a new instance of package editor.

Try this:

1. Open SFXCharacterClass_Adept.pcc (LE3 unmodified) in a new Package Editor instance (don't resize it, leave default size)
2. Expand MappedPowers array
3. Click on Singularity (i.e. the first array item)
4. Click on the dropdown to give it focus so the text is selected
5. Press down arrow 10 times

Not only the controls will disappear, but the focus will move to the array item itself so that the next down arrow keypress is going to move selection to Warp. After that happens click on any item in the array and note how controls are not reappearing until you click on the array node itself and then back on one of the child items.

[SirCxyrtyx]

I've slimmed down several of the buttons to ameliorate the issue in the latest nightly. Obviously not a full fix but it should make situations where the set button gets pushed off the end a lot rarer.

Still pondering the other issues.

[levicki]

@SirCxyrtyx Thanks.

You might even slim those buttons down further if you rename "Array Elem" to "Item".

Also in my opinion it would be best if that dropdown was specified with fixed maximum possible width needed for the longest allowed class name (and default form width adjusted accordingly) so it does not need to resize and push other GUI elements out. Moving UI elements and UI elements that change position contextually are bad for muscle memory and should be avoided if possible.

As for the point 3 you could solve that by always showing both down and up arrow buttons in fixed order and then disabling (not hiding):

• up button on first item
• down button on last item
• both buttons on an empty array

[SirCxyrtyx]

Array controls take up even less space, and are always visible now, just disabled when not relevant.

[levicki]

@SirCxyrtyx Hey thanks, that is really great!

Sorry for not creating separate issues instead of sticking everything in one issue, will try to do better next time.

//fixes bad WPF default. Users aren't going to not want to know what a button does just because it's disabled at the moment!

Also, being a developer myself, this made me laugh. So thanks for that as well :-)