Add modifiable FormSpec size types

[v-rob]

This PR adds multiple different size types of FormSpec sizing types. All new types require real_coordinates to be set to true. This is an expansion of #8630 (I meant to continue it, but I messed it up and accidentally deleted it while trying to rebase -- I'm still trying to figure out Git).

There are four new types of sizing: stretch, fill, fit, wide, tall, and mini. These are illustrated in the below image (black is Minetest window, red is FormSpec):

^{In order: normal (false), fit, fill, stretch, mini, wide, tall}

• fit is as big as possible without being cut off.
• fill is as big as possible without being bigger than the side of the screen, so the form will always be cut off.
• stretch stretches coordinates to make the form match the screen size, so things like images might look lopsided.
• wide is as wide as the screen, and the height may or may not be cut off depending on the screen size.
• tall is the same as wide but with the height as opposed to the width.
• mini works as a single pixel per coordinate. Certain things (like labels) won't work in mini. There is a note in lua_api.txt that states that mini should not be used for normal forms, only for specialized purposes.
• Everything except mini may not quite meet up with the edge of the screen when they should due to imgsize being integers, not floats.

To specify which system to use, you have to use the third parameter in the size element, e.g. size[10,5,fit]. The old behavior of true for fixed size has not been changed for compatibility (although I don't think any mods use it).

Screenshots

fit, fill, and stretch FormSpec:

size[1,1,<type>]
real_coordinates[true]
box[0.25,0.25;0.25,0.25;#000000]
box[0.5,0.5;0.5,0.5;#FFFFFF]

fit

fill

stretch

wide

size[5,1,wide]
real_coordinates[true]
box[0.25,0.25;0.25,0.25;#000000]
box[0.5,0.5;0.5,0.5;#FFFFFF]

tall

size[1,5,tall]
real_coordinates[true]
box[0.25,0.25;0.25,0.25;#000000]
box[0.5,0.5;0.5,0.5;#FFFFFF]

mini

size[20,20,mini]
real_coordinates[true]
box[5,5;5,5;#000000]
box[10,10;10,10;#FFFFFF]

This PR is Ready for Review.

[Desour]

Great!

What would speak against a new element with that you can change the imgsize multiple times in a formspec? (Or maybe add this to the container element in addition to to size?)

[v-rob]

If you change it midway, only imgsize would be changed, so it would be aligned to the top-left corner of the form like always. So, for instance, if the form started out with fit, if you changed it to fill, it would be as if the elements were in a fill form that is offset to the position of the top-left corner of fit.

If I added it to container, it could be made to act as though it made a new instance of size without drawing a new rectangle. This might look like container[5,5,fit]. If I did this, this should most definitely be merged after style because it would probably require noclip in many cases.

BTW, when is someone going to fix the Xcode compiler for Travis CI? It's rather annoying having the check fail half the time because it's outdated.

[SmallJoker]

What would be possible use-cases of tiny (does not incorporate with the coordinate system) or stretch (goes off-screen, unusable)?

[v-rob]

On the contrary, stretch never leaves the screen. It is the exact size of the screen (it's the very middle one in the top diagram). I think you mean fill.

fill makes it so that it will always be as big as the larger screen dimension. The point of fill is for forms to make a form where only the center is actually used for the actual form elements while the area around is just used for decoration that can be cut off easily.

An example of this would be like a fullscreen bgcolor that is actually an image: You start with something like fit, change to fill (with container[<x>,<y>,<size type>,<centered>] which doesn't work properly just yet), make an image that is as big as the form (like a desktop background for a computer mod), and then change back to the first thing. fill would be better than stretch here because the image, in this case a desktop background, shouldn't be warped with stretch, and fit wouldn't make it as big as the screen.

Another use-case is that, since you can change size types at will, you can make a form that starts with stretch for a full-sized form but changes to fill for certain things like images that shouldn't be warped by stretch's lopsided coordinates. You would use fill as opposed to e.g. fit or false since the coordinate should be as big as possible, which is what fill does.

tall and wide can also be cut off if they are tall/wide enough. They never leave the height/width of the screen, respectively. This is similar to fill in that the rest of the form can be used for decorational purposes, but in this case will never be cut off in a specific direction.

As for mini (not tiny, that doesn't exist), each coordinate is a pixel, which is, at the moment, pretty much useless. The purpose for it is if a CSM (and later SSCSM) could get the current Minetest window dimensions (like through a minetest.get_screen_size() or something like that) and then dynamically create a form that needs special considerations. I added it right now although it is basically useless currently because it's only 3 extra simple lines of code.

[v-rob]

I'm considering closing this because changing the coordinates can have bad side effects. I can't think of the examples I was thinking about earlier, but this PR could mess up a lot of things with no easy fix. I think it's not worth the bugs, maintenance, and trouble to both MT and mod developers.

If anyone considers this indispensable, then I'm willing to listen.

[rubenwardy]

Up to you. I think that we can make an alternative main menu which doesn't need this feature, and so doesn't invoke all the issues that could come with it

[paramat]

I will trust the author on whether this should be closed =)

[SmallJoker]

fit would be a great addition - or a ratio setting to control how much to "fit" the formspec to the screen edges. It would be especially helpful for wide or big formspecs in general.