Fixing GodSVG's messy infrastructure.

[MewPurPur]

Just writing out what's on my mind right now, as I try to figure out a good infrastructure that would allow to make SVG elements and attributes configurable from multiple places.

This post might be edited a few times as I rethink things.

New approach

SVG singleton

The core idea is that the SVG singleton will hold data, which will be the defacto way to manipulate anything about the SVG. This data will be independently able to be manipulated by:

• The CodeEdit, which displays the code of the SVG. In the future, I want to make it editable. Manipulations will only happen when the SVG inside it is valid.
• The inspector, which shows all the editable properties. Manipulations will happen when tags are moved, deleted, added, or attributes are changed.
• The draggable control handles. Manipulations will happen when they are being dragged.

Data structures

As before, there will be:

• SVGData, holds width, height, and an array of SVGTags. (I know this is just a tag, but right now I think this makes more sense)
• SVGTag, with a title and a Dictionary of Strings to SVGAttributes. There are various types of SVGTags, each having their own titles and attributes.
• SVGAttribute, with a type (e.g. color, int, flag, enum) and a value.

This is a rough simplification. So, these RefCounteds should also emit specific signals when they are changed.

• SVGAttribute would have a value_changed() attribute. SVGTag would be subscribed to this and emit attribute_changed() itself.
• SVGTag will have just the attribute_changed() signal for now. SVGData will be subscribed to this signal and emit attribute_changed() itself.
• SVGData will have an attribute_changed() signal as explained. It will also have resized(), tag_deleted(), tag_added(), tag_moved(), and tags_changed_unknown() signals.

TODO: What about individual path commands in a path definition?

TODO: How to signal information about which specific things updated?

Display

The "Display" TextureRect will be subscribed to all SVGData signals with its queue_svg_update() function, always updating the SVG when something changes.

CodeEdit

Talking: When I make it editable, I plan to make it so after every edit, the text is checked for being a valid svg string. If it is, then gather from it all the values needed to make up a width, a height (I'll address viewBox later), and an array of SVGTags, and assign all that to the existing SVGData. This will emit the tags_changed_unknown() and resized() signals.

Listening: It will listen to all SVGData signals and use tags_to_string() to translate the data. But if it's currently being edited, it won't change its text. Unlike other ways to edit the SVG, we don't want to change the text to a standard generated one while the user is editing it.

Draggable handles

They will be handled in a TextureRect overlaid on top of the SVG.

Talking: Each handle will hold a reference to its the relevant SVGAttributes in the svg data: one for its x-pos, and one for its y-pos. While a handle is being dragged, it will use its X and Y position to update these two attributes.

Listening: All SVGData signals except for tag_moved() will be listened to. They will trigger a full rebuild of the handles, except for attribute_changed() which will search for the appropriate handle and update its x or y position.

TODO: What about individual path commands in a path definition?

Inspector

Talking: Each tag editor will hold a reference to its relevant SVGTag in the SVGData, and likewise each of the fields will hold a reference to its relevant SVGAttribute. The signals that will be emitted on each possible action are pretty self-explanatory.

Listening: All SVGData signals except for resized() will be listened to. tags_changed_unknown() will trigger a full rebuild, while the others will only change the relevant parts.

TODO: How to find which tag editor or attribute editor corresponds to a certain tag? Iterating and checking?

TODO: How to handle selections? Eventually, I want to have it so selecting a tag or a handle or such is reflected in all three places (e.g. clicking on a tag highlights its handles, and also highlights it subtly in the CodeEdit)

[ajreckof]

TODO: How to handle selections? Eventually, I want to have it so selecting a tag or a handle or such is reflected in all three places (e.g. clicking on a tag highlights its handles, and also highlights it subtly in the CodeEdit)

This should be a selected_tag that would trigger a selected_tag_changed signal on being set and all place that needs to adapt should just listen to it.

Something like

var selected_tag : SVGTag : 
     set(value) : 
          selected_tag_changed.emit(value)
          selected_tag = value

TODO: How to find which tag editor or attribute editor corresponds to a certain tag? Iterating and checking?

maybe they should be listening directly to things that are emitted by the SVGTag instead of the whole SVG?

[MewPurPur]

Alrighty, having such a signal in the SVG singleton really seems like the best option.