Collapsible Inspector Elements

[HuntJSparra]

(Leaving this in draft until I finish further testing and get a better feel for how the UI is)

Description: Initial implementation of #1315. Allows user to hide the attributes and children of an element in the inspector by clicking its title bar.

Motivation: Collapsing groups is very helpful when working on more complex files.

Details: All children of main_container in element_frames are hidden if the new Element.meta_collapsed field is true for their element.

Limitations: What elements are collapsed is NOT saved, but I think this is an acceptable tradeoff for not having a separate meta file. If there is demand for this in the future, then that could be implemented independently of this PR.

[MewPurPur]

I'll keep this around, but I want to avoid changes to the inspector until the upcoming rework. Of course, feel free to use it in your own fork if you need it.

[HuntJSparra]

That makes sense to me! I need to rethink my approach anyways since it doesn't work when sync_elements() rebuilds the elements (which is very often).

[MewPurPur]

That's ok! My current thoughts about this...

• I don't want to save metadata to the SVG ever.
• There are some app-wide settings, like "Show handles", that are in SaveData, even though they aren't accessed through the settings menu. These get serialized and persist through sessions and SVG changes.
• There can be tab-specific settings in the future, people have asked me to have per-tab zoom for example. These are also serialized, but they would probably not persist through SVG changes. This is where collapsed elements may make sense to save.
• State is only for very transient things, like selections (even that might go in TabData tbh), hover, and drop locations. These don't persist.

When the SVG text is changed, a lot of this data needs to be cleared, as we can't know what part of the text specifically was changed, and doing "smart" guessing I don't think is a good idea because while in some scenarios it will make things better for users, it will likely be bug-prone and less predictable to users.

I've not tested this implementation, but I would assume it's cleared when you switch between tabs, which yeah, isn't acceptable.

[HuntJSparra]

I agree with all of that.

I've had the same thoughts about saving metadata (it goes against GodSVG's philosophy, so it's a no-go even if handling XML namespaces wasn't a pain) and "smart guessing" (it's too likely to go wrong when there are identical elements). The only option that leaves (and that I can think of) is minimizing what and when elements are rebuilt. The main causes of sync_elements() that I aware of right now are:

1. Switching tabs: As you said, it should be easy to cache the (session) metadata and restore it when tabs are switched. If the SVG has changed since the tab was last loaded, I think it's fine for the metadata to be discarded.
2. Code Editor: Similar to (1), I think it is acceptable to discard the metadata when the SVG text is directly changed. I suspect the people who heavily use this are not working in the inspector anyways.
3. Undo/Redo: This would have to be modified to work more like the drag-drop and not call sync_elements() (or minimize the syncing to the modified element or its new+old parents).

(1) is no work and (2) should be easy, but (3) is a hard problem. I'll probably look at it more on-and-off inspector rework, but those are my thoughts for now.

[MewPurPur]

Oh yeah, UndoRedo is the other thing. Right now, UndoRedo restores no data besides the SVG text, but in the future, it could change other things too, I'm not opposed to that.