godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.12k stars 69 forks source link

Implement using several different font styles and colors in one single LineEdit #10475

Open tutabot opened 1 month ago

tutabot commented 1 month ago

Describe the project you are working on

I'm hired to convert a board game to a video game. Using Godot 4.3 stable (latest stable version).

Describe the problem or limitation you are having in your project

My problem is with Godot text styling. My limitation are with lines and blocks of text the user is supposed to write into. These lines and blocks of text need to have specific styling which I have to adhere to. I have been given styling reference from the printed board game and I need to match that reference exactly. This reference has lines and blocks of text with multiple different styles. I tried to troubleshoot this issue for a few weeks now, and came to the conclusion it is not possible to solve this with Godot 4.3 stable and prior built-in features.

LineEdit and TextEdit allows the user to write into, but does not permit styling within the nodes. Only the whole node can be styled. RichTextLabel can be styled using BBCode, but lacks the built-in ability to have crucial user input features. Including a visible caret, a click to position caret, typing when selecting text replaces selected text, and so on and so forth.

There already is a proposal to add styling to TextEdit node here: https://github.com/godotengine/godot-proposals/issues/1781, but I also need styling for the LineEdit node. In my design reference, I have many text blocks and single line input prompts with two and sometimes 3, rarely 4 fonts being used. Also various colors, font sizes, outlines, ...

For example when the user writes a specific word, after finishing writing this word, it should change font and color. Ideally also custom text effects. This would be easy to do with the text_changed signal, the String class and BBCode if LineEdit and TextEdit had the BBCode feature.

My current workaround is to have a hidden RichTextLabel node under my LineEdit and TextEdit nodes for "display". As soon as the user submitted their text input, the LineEdit or TextEdit is hidden and the hidden RichTextLabel is shown. If this sounds like a solution: It's not. The user cannot click exactly at the caret position they want to write at and they have to click twice: First to switch nodes, then to click where they want to position the caret. Also, any styling disappears when switching to LineEdit or TextEdit nodes, to it looks like something broke.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Add BBCode for LineEdit

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

BBCode should work the same as in RichTextLabel.

If this enhancement will not be used often, can it be worked around with a few lines of script?

This is not the first time I would need BBCode in LineEdit and TextEdit nodes and I have seen others asking for it too. Using RichTextLabel instead is currently not a solution.

Is there a reason why this should be core and not an add-on in the asset library?

Needs to be core to allow consistent behaviour with other nodes using BBCode like RichTextLabel and hopefully TextEdit at some point.

girng commented 1 week ago

that's a good workaround and what i was thinking too. seems like you're looking for a WYSIWYG editor on RichTextLabel, perhaps a "editable" property that can be enabled. sadly, seems like a job that might involve some dev time in the RTL class, as it's kind of a beast.

from my experience, usually how bbcode gets edited is a user will click edit or a small pencil icon, and it'll convert the text to the original bbcode where the user can edit. then they hit save and it'll update the styles (i'm guessing what your workaround does).

First to switch nodes, then to click where they want to position the caret. Also, any styling disappears when switching to LineEdit or TextEdit nodes, to it looks like something broke.

you can try fading/some kind of animation so it doesn't seem broke. the user experience can be satisfied when they see an element getting "updated" per se. but probably not ideal as pure inline editing, but small tricks like that can go a long way.