Automatically expand components in Object Inspector

[Xinayder]

I feel like this is a personal issue, but I'll suggest a solution in case anyone agrees with me.

I get annoyed when I load up my Duality project, and I have to expand all the components from the selected GameObject in the Object Inspector.

Perhaps there should be an option to auto expand the components, or just save their state, so if I expand one component, save, close and reopen the editor, the component is still expanded.

[hsnabn]

I'm backing this. It would be a nice little feature to have.

[ilexp]

Yep, sounds like a good thing!

[Xinayder]

I'd like to give it a go, but I can't find the code that tracks the state of the components. @ilexp mind showing the line where it defines the state?

[ilexp]

You mean whether or not a Component PropertyEditor is expanded? That's actually happening in the GroupedPropertyEditor base class, which is part of AdamsLair.WinForms. However, there is an ExpandState interface to store and apply that. Probably the easiest way to approach this would be to modify the Object Inspector to load and save its gridExpandState as part of its SaveUserData / LoadUserData method plus some tweaking and potentially debugging.

[deanljohnson]

Probably the easiest way to approach this would be to modify the Object Inspector to load and save its gridExpandState as part of its SaveUserData / LoadUserData method plus some tweaking and potentially debugging.

It's going to be a little bit more involved. Selections don't persist through a reload of the editor and so whatever SaveUserData saves will not be valid the next time the editor opens. We could delay actually setting the expand states on load until the first selection is made, but then it would have to be the same selection as before the editor closed in order for us to expand the relevant components.

As part of implementing this we could look into saving the current object selection whenever the editor closes - at which point we could then address this issue pretty simply.

Another option would be to save the expand state based on the component type somehow - so if I expand the Transform on one object, then the Transform component of any object I select will be expanded. I feel like this may a better general solution as it will in essence store the users preference for component expansion without tying it to a specific object selection and can be used throughout their use of the editor whereas this issue just handles re-opening the editor.

[ilexp]

Another option would be to save the expand state based on the component type somehow - so if I expand the Transform on one object, then the Transform component of any object I select will be expanded. I feel like this may a better general solution as it will in essence store the users preference for component expansion without tying it to a specific object selection and can be used throughout their use of the editor whereas this issue just handles re-opening the editor.

Agreed, and assuming I understand you correctly, this is also how ExpandState already works 🙂

It's completely independent of selection and instead preserves the expanded paths in "editor hierarchy", built using editor IDs based on property name and type. No need to restore selection, and it will even remember expand states for editors that don't currently exist, until they exist again. What's missing is that this state is actually persisted, rather than being gone when restarting the editor or closing and re-opening the inspector window.

[deanljohnson]

Hmm, I did not totally understand how things were working when I wrote that last post, sorry :)

Okay - this is going to require some changes in the WinForms project to implement properly I think. ObjectInspector can't access the HashSet that ExpandState uses right now. There isn't a clean way to get the internal state of the ExpandState object in order to save it in UserData.

I have three ideas on how to make this work - which do you prefer?

1. Make ExpandState serializable and save/load it from UserData via that serialization
2. Add SaveToXML and LoadFromXML methods to ExpandState, mirroring what the docking library does.
3. Add an IEnumerable<string> property to ExpandState that allows outside code to read the internal state. Personally I don't like this option because it reveals to much information about how ExpandState works to the public.

I prefer option 2 as it has a precedent within Duality already and it fairly explicit about what it's doing.

[ilexp]

I have three ideas on how to make this work - which do you prefer? ... I prefer option 2 as it has a precedent within Duality already and it fairly explicit about what it's doing.

I think both option 2 and 3 would be decent, no strong preference here. If you're up for it, option 2 it is 👍

[ilexp]

Done by @deanljohnson. Closing this.