Proposal of improvements for authoring internal layouts

[felipesanches]

This is a followup to the conversation that started at mamedev/mame#12735

While reading this, please bear in mind that there may be features I'm simply unaware of. So I would be glad to find out that some of the concerns described below already have solutions. Please let me know if that's the case.

---

One of the reasons why I have been using SVG snippets in my layout authoring work has been due to limitations in the .lay capabilities. Below are a few examples:

Pill-shaped buttons

If using purely .lay, these would have to be poorly represented as ellipses (using a stretched disk element).

A pill shape would also be useful for representing these affordances in the Yahama MU50 panel:

Rounded corners

Similarly, many devices have rounded-corners in their control-panels. This is not strictly needed, but helps better convey the overall design of a user interface. Since the rect element does not provide a corner radius attribute (which would be one possible way to extend the .lay schema to be more expressive), I also relied on SVG to draw the overall outline of the control panel:

Stroke and fill colors

Other limitation (already seen in the screenshots above) is that the .lay schema (as far as I can tell) does not allow specifying stroke properties (such as thickness and color). So we have to either draw the same element twice with different colors and slightly different bounds to emulate the expected visuals, or we have to rely on single color elements, which jeopardize proper contrast in the user interface.

Solid fill vs. gradients

Finally, I often author artwork in SVG and keep those vector files as "source files" for the art but I end up using exported PNGs for the actual external layout because the SVG renderer does not support rendering linear gradients.

Text content (usually non-interactive control panel labels)

Maybe I am just unaware of a better way of doing it, but I have the impression that the current approach to adding text labels to layouts leads to a lot of bloat:

• One has to declare an element with a text tag, give it a text content and choose its color. And then, afterwards, reference it to actually place it with a certain set of bounds values (dimensions and position)
• Ideally there should be a way to simply declare everything at once: "place this text string with these bounds here".

Redundancy when declaring colors

I've seen the same color being declared multiple times for a set of dozens (sometimes hundreds) of elements such as text labels and buttons.

If it is so common for a layout to use the same color across many elements, there should be a way to easily declare the color only once, give it a name and then apply it to the other elements by name. I am not proposing CSS because that would be way too much complexity. But it would be nice to have some similar mechanism for applying style attributes to a selection of elements.

Conclusions

Ideally the layout XML schema could be improved to make it more expressive (with better semantic description of the elements), so that internal layouts can convey the original devices overall design more precisely without bloating the .lay file with large chunks of raw vector graphics.

The ability to include SVG files would also help the .lay file to remain readable.

We should also consider extending the layout language to include interactive elements such as sliders and rotary encoders, so that we also reduce the need for embedded lua scripting for those common cases.

Supporting linear gradient rendering on SVGs seems to be a bit harder to achieve as I believe it is a shortcoming of a 3rd party rendering library.

Ideally internal layouts should look almost as good as the external ones, perhaps only omitting branding (like logos) and things like drawings of game characters and other copyrighted content that could lead to legal issues. While staying within the bounds of what is legally allowed, internal layouts should aim at conveying the best user experience we can possibly get.