Use a SVG master file to detemine position & size of Controls

[kurasu]

With the nice affinity designer templates @cyanit and @itsmedavep have been working on its going to be really easy to create new skins that also scale well. However as the position of all interactive elements are written in code there is no way to affect them.

If we make the affinity file also export an SVG file where the bounding rectangles of all GUI elements are included (as simple boxes with IDs), we could use this as a lookup table for all the widgets we create and skins would be free to rearrange controls as they chose (the skin and potentially even controls such as sliders can be of a different size too).

Some things we'd need:

• Define textual IDs for all controls
• Make the affinity file export bounding rectangles
• SVG parser. Or if we limit the complexity by only allowing flattened SVG files we could get by with just using the XML libraries we already have.
• An object which reads the SVG and builds a map from ID -> bounding rectangles
• Modifying the code to lookup its position by ID instead of hard-coded
• Cleaning up the code so all widgets can be controlled this way (will probably need to split the LFO choose & display etc etc)

Thoughts?

[baconpaul]

fwiw my branch svgdrawing91 https://github.com/baconpaul/surge/tree/svg-drawing-91 integrates an sag parser with surge, loads an svg file, and draws a widget from it. Uses nanosvg and mostly paints correct images from simple SVG files already.

I won't ever merge that code now we are going multi-bitmap route but could easily re-add the svg parser. But I also won't delete the branch :)

I think this would be great for a post 1.6 release!

[kurasu]

We could also use the same approach to define colors used to render the controls (in another SVG file).

For reference, this is how affinity will export a simple rectangle that I named "osc".

<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="284px" height="426px" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:1.41421;"> <rect id="osc" x="113.189" y="90.551" width="89.764" height="77.953" style="fill:#e8eced;"/> </svg>

[baconpaul]

Yeah exactly. Pallete is just an svg file with rectangles with ids in it

I will revive my code sometime next week or so. Can you have affinity make an svg with a few rectangles in it for a test? If the svg files get hairy you can always flatten them with Inkscape too before reading

[kurasu]

Yeah I can bake one tomorrow-ish

[itsmedavep]

Hi:

@kurasu @baconpaul

This seems entirely reasonable. I like the idea and especially the flexibility it will afford people in the future. If we can provide a simple skin switching mechanism to the user, and make this change you can effectively let people (like myself) go wild.

Just so that Im sure I understand the requirements for designers to help get this rolling:

Take source files and add in a bounding rects.
Name the bounding rect layers with some ID (TBD).
Render SVG's

Would we need to create a bounding rect for each state in the existing sprite sheets?

[baconpaul]

#1117 will basically do this (although I’m using an XML schema at first pass to do the full layout but could move to SVG easily) so I’m going to close this one and link it to there