Add a control gallery demo

[Calinou]

This project showcases what Godot's various Control nodes can do (and what they look like, so that new users can figure them out).

I could consider adding Tree in a future PR – probably using a VBoxContainer to put it on the right of the Lists panel.

Preview

[aaronfranke]

Why not just improve the Control gallery that comes built into the engine for the theme editor?

[Calinou]

@aaronfranke The theme editor's control gallery seems good enough right now, but I think it serves a different purpose.

The one I'm adding here is specifically meant to be referenced in the documentation as a screenshot, so that new users (who may not even know about the theme editor) know which Control nodes they should use to implement a given UI feature.

In contrast, the control gallery in the theme editor already expects you to have UI development knowledge.

Also, this demo can run as a standalone project, which could be useful for regression testing in the future (checking the exact UI layout for unexpected changes over Godot versions).

[aaronfranke]

I changed my mind, I think this is a good idea. So now it's time to look for issues :)

I think the stretch mode should be set to "disabled" (and we can set aspect back to its default of "ignore").

When clicking on MenuButton and hovering or clicking on Actionitem, nothing happens and these errors appear:

E 0:00:04.231   get_node: Node not found: 1.
  <C++ Error>   Condition "!node" is true. Returned: __null
  <C++ Source>  scene/main/node.cpp:1381 @ get_node()

E 0:00:04.231   _activate_submenu: Item subnode does not exist: 1.
  <C++ Error>   Condition "!n" is true.
  <C++ Source>  scene/gui/popup_menu.cpp:151 @ _activate_submenu()

When pressing Control and hovering over LinkButton, nothing happens and these errors appear:

E 0:00:04.700   get_node: Node not found: 1.
  <C++ Error>   Condition "!node" is true. Returned: __null
  <C++ Source>  scene/main/node.cpp:1381 @ get_node()

E 0:00:04.700   get_node: Node not found: 3.
  <C++ Error>   Condition "!node" is true. Returned: __null
  <C++ Source>  scene/main/node.cpp:1381 @ get_node()

[Calinou]

I think the stretch mode should be set to "disabled" (and we can set aspect back to its default of "ignore").

Maybe, but this breaks the demo rendering on mobile and hiDPI displays where text will be tiny. I'd prefer demos to be working nicely in those scenarios out of the box. Otherwise, we'd have to wait until godotengine/godot#21446 is merged which won't happen anytime soon.

[aaronfranke]

@Calinou It's not good as-is because it's not rendering at a higher resolution, it's just stretching, and it looks ugly:

If you want to implement a way for this to look good at high resolutions, that would be ideal (otherwise I would prefer no scaling to bad scaling). I took a look at the other demos and they seem to be able to handle scaling well, this is from the Translation demo:

[Calinou]

@aaronfranke I could add a DynamicFont to this demo, but this means we have to add yet another copy-pasted TTF file to this repository, bloating it even further 😛

godotengine/godot#39603 will solve this, but it will only be merged for 4.0.

[aaronfranke]

$ ls -ls *.otf
68 ... Titillium-BoldItalic.otf
56 ... Titillium-Bold.otf
68 ... Titillium-RegularItalic.otf
60 ... Titillium-Regular.otf

A few hundred kilobytes (or less... don't we only need one of these?) isn't a huge sacrifice for the sake of overcoming Godot's limitations, if we indeed desire high-DPI compatibility in this demo (and I guess all GUI demos). Otherwise, I would just set stretch mode to disabled, and then we can worry about high-DPI compatibility in Godot 4.0 after godotengine/godot#39603 solves this.

[Calinou]

@aaronfranke Alright, I added a DynamicFont and updated the screenshot.

(or less... don't we only need one of these?

We need several font weights for the RichTextLabel demo, at least until support for variable fonts becomes available in 4.0.

[aaronfranke]

The text looks good now when scaled. However, the console errors I mentioned here still exist.

[aaronfranke]

Merged as #569.