Edit text after double-clicking a Control in the 2D editor#47784
Edit text after double-clicking a Control in the 2D editor#47784Calinou wants to merge 1 commit intogodotengine:masterfrom
Conversation
|
I think this is really cool in terms of functionality, and quite frankly my first thought when I started using Label and RichTextLabel nodes was "Why can't I just click there and write there on the Button/Label?" This would make editing text so much more intuitive. However in terms of visuals I still find this quite confusing. Is there really no way to write directly in the Button/Label? Do we really need that additional halve transparent box on top? |
Positioning the cursor is going to be a pain, especially on RichTextLabel where font sizes and spacings can vary inside the label. To help with text readability, I can make the TextEdit use a bold font. |
I don't understand. In this video you are also positioning the cursor just at the text end. In my current project, where I want to allow the player to change the content of various Labels and RTL and Buttons, I currently swap them with TextEdit nodes of the same style. Once the player confirms the change (Ctrl+Enter, clicks a ☑️ symbol, or clicks outside), I swap it back to Label, RTL, or button. |
By "positioning the cursor", I mean drawing the cursor at the correct location and ensuring text selection works as expected. I wasn't referring to the initial cursor position when you double-click the text (which is always at the end of the text right now). Swapping nodes in the editor sounds risky, since you could save the scene while the dialog is active and end up in a broken state. Also, if the node is placed within a container, things could go awry if size flags are different. |
Well I guess this depends on how Godot handles saves and crashes. If Godot would save everything as is, this would not be a problem. Or if it would wait with the save until the text is confirmed or exited. Or if it would treat the a save as and exit form the text edit. My point is, form a user perspective, all nodes with text should behave like the Textedit node by default in the editor. Maybe they therefore need to be Textedit nodes as long as they are displayed in the editor (if this makes any sense) If having an overlay is the only option (which is imho a lot uglier - if not disruptive like the online docs API search bar), then it would probably a good idea to make the overlaying box not less readable because transparent. Darkening the surrounding area using an opaque panel and making it the only input like a pop up, would make it a lot more clear what it going on, where the focus should be and the text a lot more legible. |
b7e3360 to
7a7d12a
Compare
This operates on the CanvasItem node's `text` property. This works with most built-in Controls such as Label, BaseButton, RichTextLabel, etc. This will also work on user-defined nodes that have a `text` property.
7a7d12a to
5fbec08
Compare
This operates on the CanvasItem node's
textortitleproperties (titleis only used if there is notext, e.g. for FoldableContainer).This works with most built-in Controls such as Label, BaseButton, RichTextLabel, etc. This will also work on user-defined nodes that have a
textproperty.This partially addresses godotengine/godot-proposals#1542.
TODO
textproperty. User-defined nodes could have such a property, though.Preview
double_click_text_editor.mp4
Edit: Now using a bold font for greater readability: