Improve dialog input validation

[KoBeWi]

We have a standard way of validating input in dialogs: a bottom panel with errors. godotengine/godot#78744 officially standardized it as a new class and now every dialog that does validation uses that class.

However godotengine/godot#76778 (comment) raised a concern that there is no visible association between the errors and the invalid input fields. This mostly applied to the plugin creation dialog, as it had its own way to validate input, by showing small icons next to each field, and now it's lost after the new validation was added.

So I'm opening this to discuss whether we want to add such association to the new validation class and how it should look. I made 3 quick mockups.

• Tint the fields red.
  
  It shows which fields are wrong, but you still don't know what error comes from where.

• Tint the field red when hovering error.

godot.windows.editor.dev.x86_64_IOrTG05fCa.mp4

Variation of the above that makes visible association between errors and fields.

• Show error icons next to invalid fields.
  
  The method used previously in the plugin dialog. It would be in addition to the error panel. It can either not show an error (making it similar to the first option), show error in tooltip (kinda redundant) or highlight the associated error label when hovered.

Feel free to suggest other options. Or maybe showing errors is enough and we don't need any improvements.

[YuriSizov]

I think that the validation panel works best when we need to report a complex problem (affecting multiple fields, for example), or if we only have like one or two fields in the form.

In a more evolved form like any of our creation dialogs tips located directly next to the problematic field work better. I don't think contextual highlighting helps much. It can be nice to highlight the field, or fields, when you hover over an error, but it's not a substitute for the icon and a hint that we had previously in the plugin creation dialog. So it can be done in addition, but not instead. The other way around, highlighting an error when you hover over a field, doesn't work at all IMO.

So basically, both negative and positive marks next to the affected field reduce the cognitive load and help sort out the problems quicker. So I'd still go with them as the main way for reporting in more complicated forms. I think the design was fine before.

[coppolaemilio]

I made some mockups to fix how weird this dialog looks like. I never finished making edits to it but I want to share here:

The main issue I see is that we show the warnings all grouped up in a box below, while this is never the case in most of modern UI. Showing it is valid next to it and the text warning under an input is usually how you would see this sort of dialogs nowadays.

I can keep working on this dialog mockups if you like, but wanted to share it here just in case there's some new work done.

I also removed the Class Name field because it was unused and no one could explain me why it was there first (or if they did I don't remember 🤡 )

[theraot]

I believe having an static indication, which could be tinting or icons (either of which could be used for both valid and invalid fields), is better than requiring to hover, given that it works in environments without mouse (e.g. keyboard only, or touch only).

With that said, using hover to reveal the association between the fields and the validation text is a good idea. Thus, I submit to your consideration to invert it: hover on the field (or the icon). Although in this situation I'd expect that hovering to result in a tool-tip, highlighting text in the validation panel would also work.

Furthermore, for the aforementioned environments without mouse, you can highlight the text in the validation panel that is associated with the field that currently has focus.