Support icon sizing in themes

[andy-noisyduck]

Describe the project you are working on:
Mobile game

Describe the problem or limitation you are having in your project:
Godot supports using custom images for various icons used in themes (for example, the checkbox supports graphics for the checked / unchecked states). Any icon chosen is rendered at 1:1, with no option to specify an icon size in the editor.

Reusing an existing GUI texture is not possible unless the sizes match exactly. Currently the only way to mitigate this is to import multiple versions of the textures - one for each size you need. The workflow to do this is a little annoying, but more importantly, when building mobile games it's a waste of precious texture memory.

It also makes it harder to build themes that can run at a higher resolution than project settings (e.g. retina display support). If you add a 3x size texture to the theme as the icon will simply be 3 times the size. You could fix this by having your project settings as retina sized to start and then scale everything, but that's not always practical.

On a side note, this problem isn't just found in themes. There is a lack of control on icon sizes for GUI elements in general. Buttons are the obvious example. They at least have the "Expand Icon" property to automatically scale the icon up or down to the button, but there is no finer method for finer control than that. If button text is a fixed size, then a free scaling icon doesn't normally make sense. Most of projects have ended up with custom button classes - which is a bit of shame.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
When choosing an icon for a theme, as well as being able to select the image, there would be size options to override the dimensions. This lets the author decide exactly how big the icons should display, and the renderer can up/downscale accordingly.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Select an icon as normal for the appropriate theme element (e.g. Check Box -> Icons -> Checked), then specify custom dimensions if required, ideally as a property shown directly underneath the icon in the inspector.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
You could build custom versions of the controls to achieve this instead of using themes (which is what I've ended up doing).

Is there a reason why this should be core and not an add-on in the asset library?:
Godot clearly has aspirations to have fully featured GUI system, of which Controls and Themes are already an integral part. This is just adding support for a reasonable use case that uses them both.

[Calinou]

Related to #6. Personally, if I were to design a mobile game, I'd design the UI elements for 1280x720 or 1920x1080 (depending on whether the game targets low-end or high-end devices) and be done with it. Thanks to the 2d stretch mode and expand stretch aspect, the UI will be able to adapt for any resolution and will still look decently sharp on most phone displays. (For reference, the Nintendo Switch uses a lower display density than most phones out there.)

It also makes it harder to build themes that can run at a higher resolution than project settings (e.g. retina display support). If you add a 3x size texture to the theme as the icon will simply be 3 times the size. You could fix this by having your project settings as retina sized to start and then scale everything, but that's not always practical.

There is a project setting to do this precise thing 🙂

Set the project width and height to the desired resolution in the Project Settings, then set Test Width and Test Height to the default window size you'd like.

[andy-noisyduck]

There is a project setting to do this precise thing 🙂

Set the project width and height to the desired resolution in the Project Settings, then set Test Width and Test Height to the default window size you'd like.

Ah, I hadn't considered that. That makes a bunch of sense.

I think the re-use case is still valid, but if that's the only use-case then it might be too niche to make sense in core now.

[Calinou]

Duplicate of #6.