[Mod] Scarlet (Formspec Layout Preprocessor) [scarlet]

[sorcerykid]

Scarlet Mod v1.4 Beta
scarlet by sorcerykid

Scarlet (Saner Coordinates and Rational Layouts Expression Translator) is a thin-wrapper library that provides consistent and uniform layout of all elements within Minetest formspecs. Being a purely Lua-based implementation has the advantage that backwards compatibility even with legacy versions of Minetest is assured. No patches and/or upgrades to the engine are required.

Q: Do I need to add Scarlet as a dependency to my mods?

It is entirely possible to use Scarlet to generate Minetest-compatible formspec strings during development and then place those strings into the code. Scarlet need not be a runtime dependency. While intended as a wrapper library, it is ultimately just a preprocessor.

Q: Is Scarlet a bitmapped GUI, or are forms scalable?

Scarlet supports multiple units (cell, point, and image) that all scale to the user's screen DPI. Pixel precision is not even the goal of Scarlet, although a unit is provided for this purpose (dot).

Q: What future plans are in the works for Scarlet?

The forthcoming release of Scarlet will add support for themeable in-line templates and user-defined element parsers in addition to helper functions for text formatting and input processing.

Q: Is Scarlet becoming obsolete as Rubenwardy claims?

Scarlet is a preprocessor that supports multiple units of measurement, embedded arithmetic expressions, and a variety of aliased and enhanced elements. Scarlet includes a command-line calculator, in-game calculator, and DPI visualization tool. Scarlet is backward compatible and tested on all versions of Minetest as far back as 0.4.14. So it is nowhere near obsolete, and I intend to maintain it as long as possible.

• 
  

Here is a quick summary of the various oddities and inconsistencies (many of which are still undocumented) that I have addressed:

• Strange, fractional offsets
  With the exception of pwdfield[], field[], and textarea[], all other elements are offset from the form origin. As a result, precise alignments must be achieved through trial-and-error. Therefore, I added an optional border parameter to the margin[] element.
• Image ratios, only sometimes
  For some reason, background images and button images are scaled according to inventory slot spacing whereas images and item images are scaled by inventory image dimensions. Therefore, I provided a means to specify either unit of measurement.
• Overloading of elements
  Certain elements like background[] and tooltip[] accept different lists of parameters. This is both error-prone and difficult to remember. Therefore, I separated these into distinct elements: background[] vs. bgimage[] and tooltip[] vs. area_tooltip[], etc.
• Height restriction of buttons
  Text-only buttons are constrained to a uniform height. However, an undocumented feature of image_button[] exists to bypass this limitation. Therefore, I mapped the button[] element to image_button[] with the appropriate parameters behind the scenes.
• Backwards ordering of parameters
  All named elements expect the name parameter to follow the position and dimension parameters, except for image_button[] and item_image_button[] where the texture name or item name takes precedence. Therefore, I reversed these two parameters.

Scarlet has been successfully tested with Minetest 0.4.15, 0.4.17, and 5.0.0. This mod is still in alpha and changes are to be expected. However, I will make every effort to reduce breakage between versions whenever possible.

Repository:

https://bitbucket.org/sorcerykid/scarlet

Download Archive (.zip)
Download Archive (.tar.gz)

Dependencies:

ActiveFormspecs (optional)

Source Code License:

The MIT License (MIT)

Installation:

1. Unzip the archive into the mods directory of your game
2. Rename the scarlet-master directory to "scarlet"
3. Add "scarlet" as a dependency for any mods using the API

Usage Instructions

Formspec elements in Minetest currently do not conform to any standard units of measurement. In fact, positions and dimensions can vary widely as illustrated in the following table.

• 

A cell unit represents the interval between the left (or top) edge of one inventory slot to the left (or top) edge of a subsequent inventory slot. An image size unit represents the width (or height) of one or more inventory images. A slot unit represents the interval between the left (or top) edge of one inventory slot to the right (or bottom) edge of a subsequent inventory slot.

For simplicity and convenience, Scarlet provides six interchangeable units of measurement: dot, point, slot, cell, image size, and button height. Button heights, of course, only apply to y-axis position and dimension values. And slots pertain solely to dimension values.

• 

For each of the following elements, <w>,<h> is a dimension value and <x>,<y> is a position value. Note that a few elements only accept a <w> dimension value.

• size[<w>,<h>]
  
  size[<w>,<h>;<border_x>,border_y]
  
  container[<x>,<y>]
  
  margin[<margin_x>,<margin_y>]
  
  list[<inventory_location>;<list_name>;<x>,<y>;<columns>,<rows>;<starting_item_index>]
  
  box[<x>,<y>;<w>,<h>;<color>]
  
  image[<x>,<y>;<w>,<h>;<texture_name>]
  
  item_image[<x>,<y>;<w>,<h>;<item_name>]
  
  bgimage[<x>,<y>;<w>,<h>;<texture_name>]
  
  background[<w>,<h>;<texture name>]
  
  label[<x>,<y>;<label_text>]
  
  vertlabel[<x>,<y>;<label_text>]
  
  checkbox[<x>,<y>;<name>;<label>;<selected>]
  
  button[<x>,<y>;<w>,<h>;<name>;<label>]
  
  button[<x>,<y>;<w>,<h>;<name>;<label>;<noclip>;<border>]
  
  button_exit[<x>,<y>;<w>,<h>;<name>;<label>]
  
  button_exit[<x>,<y>;<w>,<h>;<name>;<label>;<noclip>;<border>]
  
  image_button[<x>,<y>;<w>,<h>;<name>;<texture_name>;<label>]
  
  image_button[<x>,<y>;<w>,<h>;<name>;<texture_name>;<label>;<noclip>;<border>;<pressed_texture_name>]
  
  item_image_button[<x>,<y>;<w>,<h>;<name>;<item_name>;<label>]
  
  dropdown[<x>,<y>;<w>;<name>;<item_1>,...;<selected_idx>]
  
  textlist[<x>,<y>;<w>,<h>;<name>;<item_1>,...;<selected_idx>]
  
  pwdfield[<x>,<y>;<w>;<name>]
  
  field[<x>,<y>;<w>;<name>;<default_text>]
  
  caption[<x>,<y>;<w>,<h>;<caption>]
  
  textarea[<x>,<y>;<w>,<h>;<name>;<default>]
  
  horz_scrollbar[<x>,<y>;<w>,<h>;<name>;<value>]
  
  vert_scrollbar[<x>,<y>;<w>,<h>;<name>;<value>]
  
  table[<x>,<y>;<w>,<h>;<name>;<cell_1>,...;<selected_idx>]
  
  tabheader[<x>,<y>;<w>,<h>;<name>;<value>]
  
  area_tooltip[<x>,<y>;<w>,<h>;<tooltip_text>;<bgcolor>;<fontcolor>]

Measurements may be expressed as integers or floating points, with the exception of dots which are always integers. Each value may be suffixed by a single letter indicating the unit of measurement. Here are some examples:

• box[0p,0p;100p,10d;#FFFFFF]
  Box 100 points wide and 10 dots tall.
  
  button[0c,0c;2s,1b;clickme;Click Me!]
  Button 2 slots wide and 1 button height tall

Position values are signed, whereas dimension values are unsigned. This permits placement of elements anywhere relative to the form origin and any parent containers.

• 
  
  
  
  

All units of measurement are independent of pixel density, with the exception of dots which have a 1:1 correspondence to pixels. Hence, if you need pixel-based precision, then you should use dots with the correct translator above. Points will scale to maintain a consistent dot pitch of 72 points per inch, in accordance with the official standard (this assumes that the client's screen_dpi setting is correct).

A handy in-game tool is provided to check your screen DPI settings by typing /dpi into chat.



There may be cases when you need to calculate position or dimension values from different units of measurement. Below is a conversion table for this purpose:

• 1.0b = 0.3c (y-axis)
• 1.0i = 0.8c (x-axis), 0.866c (y-axis)
• 1.0p = 0.020c (x-axis), 0.022c (y-axis)

And two common values used in rendering formspecs:

• Form padding:
  0.3c (x-axis), 0.325c (y-axis)
• Slot spacing:
  0.2c (x-axis), 0.133c (y-axis)

An interactive GUI-based calculator can be accessed by issuing the /scarlet command (requires "server" privilege).



The numeric button pad is fairly self-explanatory. The bottom rows of buttons are grouped by units and variables respectively. Below that are two drop-down menus to switch between x-axis vs y-axis and 72 dpi and 96 dpi.

All standard units of measurement are supported (except for slots) in addition to the following four preset variables:

• $B = button height
• $P = form padding width or form padding height
• $S = slot spacing width or slot spacing height
• $R = the result from the previous calculation

Simply type an arithmetic expression directly into the input field or use the buttons for this purpose. When finished, press the equals button to evaluate the expression. The result will be displayed in the input field for easy copying and pasting into another application. If, however, the expression is invalid, then the "Ready" indicator will change to "Error", allowing you to correct your mistake.

The "C" button clears the input field in preparation for a new entry. The "CE" button reverts the input field to the last recorded entry (which can be useful for undoing a typo as well as recalling an expression after evaluation).

I also included a command line unit-conversion calculator. This is particularly convenient for working offline, rather than repeatedly launching the Minetest client. Aside from the GUI, this tool offers most of the same functionality as the in-game calculator, in addition to nine user-settable variables.

To launch the calculator, just switch to the Scarlet subdirectory and type awk -f calc.awk from the shell.



The script reads from STDIN, so you can feed it a plain text file with a list of commands or you can enter each command manually, in which case a prompt will appear. Here are the available commands:

• dpi <dpi_spec>
  Specifies the screen dpi to be used in subsequent calculations.
  
  axis <axis_spec>
  Specifies the axis of measurement to be used in subsequent calculations.
  
  eval <expr>
  Evaluates the given arithmetic expression, displays the result, and stores the result in preset variable $R.
  
  set <var_spec>
  Sets the given user variable to the previous result
  
  add <var_spec>
  Sets the given user variable to the sum with previous result
  
  sub <var_spec>
  Sets the given user variable to the difference with the previous result
  
  get <var_spec>
  Displays the value of the given user variable (similar to eval <var_spec> but the preset variable $R is unchanged).

The user variables are numbered $1 through $9 and they default to zero until set. You can store any results into these variables, and they will persist for the duration of the session.

Scarlet provides two preset translators that can be used immediately in your mods. Both functions return a Minetest-compatible formspec string:

• scarlet.translate_96dpi( fs )
  scarlet.translate_72dpi( fs )

A general-purpose translator is also available for further customization:

• scarlet.translate( fs, screen_dpi, gui_scaling, has_padding )
  • fs - the formspec string to be processed
  • screen_dpi - pixel density of the client display in dots per inch (72 is default)
  • gui_scaling - scaling factor by which to render the GUI widgets (1.0 is default)
  • has_padding - whether to maintain the legacy padding (false is default)

Both screen_dpi and gui_scaling should match the client setting whenever possible. Otherwise, the default values above should suffice as a fallback.

Here is an example of a seemingly basic formspec that would ordinarily take some trial and error to layout properly due the numerous inconsistencies described earlier. But, with Scarlet it is very straightforward.

Code: Select all

local fs = scarlet.translate_72dpi(
     "size[4.0s,3.3s]" ..
     "no_prepend[]" ..
     "bgcolor[#333333;false]" ..
     "caption[0c,0c;4s,1c;Please enter your credentials to access this restricted area:]" ..
     "label[0c,1c;Username:]" ..
     "field[0c,1.5c;2s;username;]" ..
     "label[2c,1c;Passcode:]" ..
     "pwdfield[2c,1.5c;2s;passcode]" ..
     "button[1c,2.5c;2c,1b;confirm;Confirm]"
)

By running this string through the translate_72dpi() function, Scarlet produces the following output (newlines added for readability)"

Code: Select all

size[4.000,3.067]
no_prepend[]
bgcolor[#333333;false]
textarea[0.300,-0.025;4.000,1.483;;Please enter your credentials to access this restricted area:;]
label[0.000,1.117;Username:]
field[0.300,2.175;2.000,0.000;username;;]
label[2.000,1.117;Passcode:]
pwdfield[2.300,2.175;2.000,0.000;passcode;]
image_button[1.000,2.500;2.200,0.833;;confirm;Confirm]

It is important to note that Scarlet performs inversions of the "black magic" algorithm in guiFormSpecMenu.cpp. Due to the way that pixel offsets are internally computed by that algorithm (repeated typecasting between floating points and integers), this occasionally introduces rounding errors which may result in some elements being drawn 1 pixel larger or smaller than anticipated.

[v-rob]

Funny, I was working on something like this a while ago. I quit work on it because I couldn't stand the slight pixel imperfections and the unmodifiable heights of fields, dropdowns, and the like, and went and made #8524 instead.

But you seem to have done this pretty well. Nice job!

(BTW, why did you test it in 0.4.15? Seems kinda unnecessary... :-P)

[Lone_Wolf]

Nice work! This will be useful

[sorcerykid]

Version 1.1b Released

A new version of Scarlet is ready for download. Here is a complete change log:

• Major code reorganization into multiple classes
• Added support for pixel-based unit of measurement
• Further simplified some "black magic" constants
• Implemented margins to simulate container element
• Revamped translation interface for stateful use
• Various improvements to element parameter parsing

I completely overhauled Scarlet under the hood, not only to streamline execution but also to support stateful logic during preprocessing.

The new margin[] element is one such example. It is intended to offer a backwards compatible solution for the broken container[] element, which was just fixed in Minetest 5.0. With margin[], however there is no longer the risk of misalignments due to the lingering bug in 0.4.x.

• margin[x,y]
  margin_end[]

If the position parameter is unspecified, then the default formspec margin of 0.375i will be used. In every other respect, this element behaves as its predecessor, providing a means for nesting physical elements by a given offset.



Note: Minetest 5.0 is using a different GUI widget for static textareas, hence why the text is not rendered flush with the margin. This discrepancy will be resolved in the next version of Scarlet.

I also added a new "Dot" unit of measurement. The dot, like the point, equates to 1 pixel at 72 dpi. However, the dot always represents a physical pixel regardless of the pixel density of the display, whereas a point will scale to maintain a consistent dot pitch of 72 points per inch, in accordance with the official standard. To summarize

• 1 dot = 1 pixel (at any dpi)
• 1 point = 1 pixel (at 72 dpi)

Here is a simple demonstration of how dot and point units compare. Assuming that screen_dpi is set correctly in the Minetest client, then the upper bar should correspond to 72 on-screen pixels and the lower bar to 1 physical inch at the selected DPI.



So if you need pixel-perfect accuracy, use the dot -- but beware that on high resolution screens, the elements will be rendered smaller.

[sorcerykid]

Version 1.2b Released

A new version of Scarlet is ready for download. Here is a complete change log:

• Included mod.conf and description.txt files
• Fixed parsing of list and size element parameters
• Recomputed textarea position due to engine bug
• Added padding option to generic element classes
• Implemented algorithm to compute form dimensions
• Reversed point and dot units per documentation

This is almost entirely a bug-fix release. The most noticeable change is that forms are now rendered to the correct dimensions. Previously the size[] element only performed a unit conversion yet failed to account for the borders on the bottom and right edges. In addition, caption[] elements should now be properly positioned in Minetest 5.0 (see my earlier post).

[Walker]

+1 nice

[sorcerykid]

Version 1.3b Released

A new version of Scarlet is ready for download. Here is a complete change log:

• Added method to evaluate arithmetic expressions
• Developed in-game unit conversion calculator
• Added optional padding parameter to size element
• Fixed ordering of checkbox element parameters
• Added methods to extract raw pos and dim values

For this release, I extended the size[] element with an optional second parameter for rendering vertical and horizontal borders around the form without the need for a margin[] element. By default, the classic padding of 0.3c (x-axis) and 0.325c (y-axis) will be used. If you don't want borders, then specify 0c,0c for the second parameter.

• 

I also completed work on a unit-conversion calculator. This feature can be acccessed in-game via the new /scarlet command:

• /scarlet <axis> <expr>

The <axis> parameter is either "x" or "y" and the <expr> parameter is an arithmetic expression of unit-values or variables (only addition or subtraction are supported). The final result will be computed as cell units.

Code: Select all

/scarlet x -1c+2c
Result: 1.000c

/scarlet y $P+1.5i-$B
Result: 0.925c

/scarlet x $B
Result: 0.7c

All standard units of measurement are supported (except for slots) in addition to the following four preset variables:

• $B = button height
• $P = form padding width or form padding height
• $S = slot spacing width or slot spacing height
• $R = the result from the previous calculation

An interactive GUI-based calculator can be accessed by issuing the /scarlet command, but without any parameters.

• 

The numeric button pad is fairly self-explanatory. The bottom rows of buttons are grouped by units and variables respectively. Below that are two drop-down menus to switch between x-axis vs y-axis and 72 dpi and 96 dpi.

Simply type an arithmetic expression directly into the input field or use the buttons for this purpose. When finished, press the equals button to evaluate the expression. The result will be displayed in the input field for easy copying and pasting into another application. If, however, the expression is invalid, then the "Ready" indicator will change to "Error", allowing you to correct your mistake.

The "C" button clears the input field in preparation for a new entry. The "CE" button reverts the input field to the last recorded entry (which can be useful for undoing a typo as well as recalling an expression after evaluation).

[Wuzzy]

Sorry, I will ignore Scarlet forever since it's non-official.

The real solution is to fix the engine. Period.

It's bad design if we need mods to work around design failures of the engine.

But good work in documenting all that horrible dark magic that the engine does atm, I gotta admit.

[v-rob]

I agree with Wuzzy, and that's why I made the PR. I like the idea of different coordinates, but I think that those should be built on the new system, not on the old. Plus, pixel inaccuracies might just be the deciding factor for certain formspecs that require perfect precision.

[sorcerykid]

Version 1.4b Released

A new version of Scarlet is ready for download. Here is a complete change log:

• Added chat command to test screen DPI settings
• Various code cleanup and consolidation
• Included command-line unit conversion calculator

Greetings all! I developed a handy in-game tool to check your screen DPI settings. Just type /dpi, and the following form will pop up.



When the screen_dpi setting in minetest.conf is correct, then the upper bar should measure 72 on-screen pixels and the lower bar should measure 1 physical inch. This is good way to visualize how formspec elements scale using point vs. dot units of measurement.

I also included a command line unit-conversion calculator. This is particularly convenient for working offline, rather than repeatedly launching the Minetest client. Aside from the GUI, this tool offers most of the same functionality as the in-game calculator, in addition to nine user-settable variables.

To launch the calculator, just switch to the Scarlet subdirectory and type awk -f calc.awk from the shell.



The script reads from STDIN, so you can feed it a plain text file with a list of commands or you can enter each command manually, in which case a prompt will appear. Here are the available commands:

• dpi <dpi_spec>
  Specifies the screen dpi to be used in subsequent calculations.
  
  axis <axis_spec>
  Specifies the axis of measurement to be used in subsequent calculations.
  
  eval <expr>
  Evaluates the given arithmetic expression, displays the result, and stores the result in preset variable $R.
  
  set <var_spec>
  Sets the given user variable to the previous result
  
  add <var_spec>
  Sets the given user variable to the sum with previous result
  
  sub <var_spec>
  Sets the given user variable to the difference with the previous result
  
  get <var_spec>
  Displays the value of the given user variable (similar to eval <var_spec> but the preset variable $R is unchanged).

The user variables are numbered $1 through $9 and they default to zero until set. You can store any results into these variables, and they will persist for the duration of the session.

Many additional features are still in the pipeline for Scarlet, so stay tuned :)

[runs]

I'm not uncomfortable with it, but I find it funny that Sorcerykid is systematically attacked in the comments of his mods. Even by developers/moderators.
Maybe it'd be personal quarrels. I don't understand, and I don't care.
But I think it's unfair because their mods are high level.

[Linuxdirk]

It's bad design if we need mods to work around design failures of the engine.

But we all know that engine changes likely never happen.

The only downside of Scarlet is that it introduces own sytax that is not compatible with default formspec syntax so Scarlet formspecs have to be completely rewritten when Scarlet becomes unnecessary one time.

[v-rob]

I don't have anything against sorcerykid, and I admire his work on this mod. I just feel that mod developers really don't want extra dependencies on their mods unless they have to. One has only to look at all the wonderful libraries and see that no one uses them but a select few.

On this particular mod, I think that this would be better handled in the engine. Something I think would be really awesome is an API for making formspecs that doesn't use the current unintuitive formspec strings. With custom elements as well. By custom element, I mean something like this: Place an image_button down with some text on it. Then, place another image_button without any text and set drawborder to false right on top of it. The result is something that looks like a button but doesn't actually click. It could be used as decoration, or a disabled button, or something like that. I like to call this a 'bevel' because it's a gradient that is decorational.

I don't want to give any more examples of these custom elements because that would be off-topic. But that's exactly the type of library I would want, not one like this that should be solved in the engine.

[sorcerykid]

It is entirely possible to use Scarlet to generate Minetest-compatible formspec strings during development and then place those strings into the code. Scarlet need not be a runtime dependency. While intended as a wrapper library, it is ultimately just a preprocessor.

This has the benefit that Scarlet is both version agnostic and future proof, whereas engine fixes are prone to break compatibility. If some new system is devised, then Scarlet will continue work as before (if not better) with only a minor patch to the algorithm. I'm of the opinion that being official isn't always a promise of design efficacy and utility, but more often than not a longer turnaround time.

That's all I'm going to say on this subject. Hopefully now we can get back on topic.

[Thomas-S]

It seems like the git repository is not accessible.

[Napiophelios]

It seems like the git repository is not accessible.

Yeah can't download the archived files either :(

2019-05-30_214517.png (26.44 KiB) Viewed 1911 times

[Thomas-S]

The repository still seems to be not accessible.

sorcerykid also does not respond to private messages regarding this topic.



This mod looks really promising, so it would be very good if it was accessible.

[Napiophelios]

she probably has set it to private.

[Lone_Wolf]

RIP. I will eventually need this for a project of mine...

[v-rob]

As PR #8524 has come closer to being merged, I've realized that this mod is less of a competitor and more of something that can work with this PR even better than either can alone. I apologize for my earlier harsh words, and I hope that you can add support for the PR when it's merged so everyone can benefit. As an option, of course, since one of the major tenants of this, as I can see, is backwards compatibility.

Anyway, more to the topic, I have a coordinate idea (if possible): Minetest's HUD uses coordinates from 0.0 - 1.0. I propose that you make a new coordinate type, relative with the suffix r that uses the coordinates in relation to the current form or container. Since this would also add relations to the sides of containers, containers would have two extra optional arguments for the other side of the container, like so: container[0.25r,0.25r;0.5r,0.5r]. This would make all elements be in relation to a box offset one-quarter of the form size in on all sides. These new arguments would be optional, defaulting to 0 since other units would have no need for these.

Also, although the HUD uses these coordinates, so do the formspec elements position and anchor. I also propose that every coordinate type in this mod can be used in these as well as the relative coordinates that they currently take. The center, though, should always be at (0,0) for any system that is not relative.

And lastly, I propose that the slot unit can be used in position and not only size since I can see a potential use case, if not only for consistency, as well as allowing button in width and the X coordinate, also for consistency.

Anyway, I hope you allow access to the repository regardless of whether you use any of my suggestions, since many people want to use this mod.

[ShadMOrdre]

sorcerykid,

Don't give up!

Ignore the "haters". I find, they are either competitors, jealous of their own inadequacies, have some other personal agenda, or are just irrelevantly STOOPID, WORTHLESS PIECES OF SHITE!

I would specifically call out those users that seem to only post negativity or criticism, but it's pointless and a waste of time, effort, and energy to try to correct those who are so self-absorbed. I'd have better luck turning my cup of coffee into a pot of gold.

To those that want to respond, go ahead. You'll be wrong from the first keystroke, and you'll be wrong when they nail the coffin shut. Try something else. Think it through to the Nth degree. And if you think you've thought it through, well, if you are responding to this comment within, say, the next week or two, you've not thought it through to the Nth degree...... Nth degree means EVERY POSSIBLE consequence. If you don't see them, you aren't thinking.

Cheers!

:)

Shad

[rubenwardy]

This is very impressive, as are most of your projects. I can see you've spent a lot of time on this

Have you considered auto-layouting? That is, having the preprocessor control the positions and sizes of children based on containers. For example, to use a vertical stack to place elements one after another:

Code: Select all

vertical_stack[1c,1c]
    button[0,0;3,1;a;One]
    button[0,0;3,1;b;One]
    button[0,0;3,1;c;One]
vertical_stack_end[]

A more complex example would have subcontainers in the stack:

Code: Select all

vertical_stack[1c,1c]
    container[0,0]
        label[0,0;Hello]
        button[1,0;3,1;a;One]
    container_end[]
    container[0,0]
        label[0,0;Hello]
        button[1,0;3,1;a;One]
    container_end[]
    container[0,0]
        label[0,0;Hello]
        button[1,0;3,1;a;One]
    container_end[]
vertical_stack_end[]

Take this "feature request" with some cynicalism, as I'm not a user of scarlet :)

[v-rob]

I have another idea: How about a new element scale[elem x,elem y;spacing x,spacing y] that changes the size of spacing and element size for all elements? For instance, scale[0.5,0.5;2,3] would make elements half as tall and wide and have spacing two times wider and three times taller between them. Spacing changes only if you're using cells/slots. I say this in anticipation of #7971, where this would be very useful.

[Lone_Wolf]

It would be nice if you could look into the downloading issue. I'd like to be able to use this for my mods. Preferably before I finish them...

[texmex]

Hi, where’s the repo?