Preview and update inline colors with a ColorPicker in the script and shader editors

[poirierlouis]

Describe the project you are working on

Prototyping features with GDScript / Godot Editor before writing them with GDExtension to improve performance later.

Describe the problem or limitation you are having in your project

Currently, you need to get a color picker somewhere else in the engine (e.g. from a Material) or on the web when you need to update a color code in the editor. This slows the process of writing, updating or picking a color code. It is cumbersome to navigate to another part of the engine or another program to pick a new color and paste it back in Godot Editor.

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

My proposal is to add a square aligned with a line of text when a color is detected. This square is filled with the detected color. The user can click on this square to open a dialog with the ColorPicker of Godot, change the value and validate the new color. The old color declaration in the line is then updated with the new value.

Square would be filled with a white background first, to reveal the alpha channel of the detected color (when used).

This is a feature you can find in IDE like IntelliJ. Such enhancement could improve engagement of the user within Godot Editor.

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

I've made an animated mock-up to show a possible solution of the enhancement I'm proposing:

1. Detect color (starts with light orange).
2. Click on preview color.
3. Pick a new color, validate new color.
4. Update line of text with the new value.

An optional application of this enhancement within GDShader:

Use Cases

• detect one color per line of text (first version).
• only parse a color from a line of text after a delay of inactivity (maybe reuse mechanism used for auto-completion).
• open ColorPicker when clicking on preview color.
• close ColorPicker when loosing focus: no update, any action requiring a focus outside of the ColorPicker.
• close ColorPicker when pressing Escape: no update.
• close ColorPicker when pressing Enter: update color's value in the line of text.
• make ColorPicker scrollable when it is not fully displayed within parent container (window).
• update color's value using the same syntax:
  • DON'T force a syntax such as Color.hex is updated to Color(r, g, b, a).
  • DO update the value using the same format.

    This rule would prevent cumbersome refactoring when using VCS. It also keep the user master of the format instead of imposing one: e.g. I use hex format for [insert reason] in my project, so I want to keep it this way across my entire project.

Parse Color Rules

GDScript Accept color class declarations:

• Color constructors
• Color.from_hsv
• Color.from_ok_hsl
• Color.from_rgbe9995
• Color.from_string
• Color.hex
• Color.hex64
• Color.html
• Color8 method
• Color constants
• other format I missed?

GDShader

• uniform vec4 my_color : source_color declaration with a default value (required).

Other text files It brings this feature in other text files, like Markdown.

• accept string format 0xRRGGBB[AA]
• accept string format #RRGGBB[AA]

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

No, it is related to Godot Editor only.

It may be frequently used, declaration of @export var COLOR := Color() can be frequent when creating nodes. Such enhancement allows one to directly update the color code from the editor, which improve experience when user is a developer.

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

It is related to Godot Editor, which is core.

[mieldepoche]

there's an addon that does (at least partially) that: https://godotengine.org/asset-library/asset/1252

[poirierlouis]

there's an addon that does (at least partially) that: https://godotengine.org/asset-library/asset/1252

Thank you @mieldepoche, I didn't know about this one. This gave me a good head start in understanding the editor of the engine.

@Calinou, thank you for fixing the title. Also I'm currently implementing this proposal and I'm willing to make a PR once it is ready and accepted.

[poirierlouis]

After asking about this proposal on Reddit, it reached around 410 likes with 26.2k views, where people brought to me known solutions, counter-arguments and new ideas. Many thanks to the community for these feedbacks.

I try to summarize the content of the thread below:

Updating an inline Color in script editor is already a feature:

When Color() constructor is written, right-click on Color, click on Pick Color to show a Color Picker, select new color, leave Color Picker to update and write the new color.

• This good solution, while hidden IMHO also lake the support of other formats. It is not shown in the PopupMenu when written with Color.hex and other static methods.
• There is no preview.
• When updating the new color, it will force-use the Color constructor with the RGB float syntax Color(r, g, b). This goes against the proposed idea to reuse the current format: Color("#ffa800") could be changed to Color("#ff7b00") instead of Color(1, 0.48235294222832, 0).

More flexible using @export and uniform:

It is convenient to use the workflow of these keywords. It requires a scene file with a script / a material file with a shader, which is fine when one only want to configure the property in a specific node.

• This proposal target a different use-case which is developer oriented only. Currently, it is not as straight forward to preview / update a color code within the script and shader editors when it is not attached to a Node / a Material.
• This enhancement is specific to the default color value written in the file. Updating the exported value from a scene file is specific to the scene itself (and potential dependencies). But some dependencies might just use the default color value. Previewing and updating the default color right from within the editor is a gain of time.

Support inline preview for multiple colors in the same line:

IDE like VSCode provide a preview per color detected in a line.

• This solution seems to be the best, but it might need more work. Is this assumption (multiple color declarations per line) widely spread in usage to be worth the development?
• It might be the best world between current right-click solution along with a preview as a prefix to the color declaration.

An addon is already implementing some of these features:

Addon is Godot v4.0 compatible only. Addon (from README screenshot) do not cover all color formats declaration. As said, and seen in the Reddit post: it requires a user to know Godot support addons, to know such feature can exist, to search for it and install it (per project).

• Integrating this in the engine would benefit every users.
• Integrating this in the engine could be backward-compatible to be cherry-picked in Godot v3.5.
• Due to refactoring between v3 and v4, this will require specific work to be merged in v3.x.

[Calinou]

Integrating this in the engine could be backward-compatible to be cherry-picked in Godot v3.5.

To clarify, new features can only be backported to 3.6, not 3.5.x. 3.5.x will only receive bug fixes.

[poirierlouis]

To clarify, new features can only be backported to 3.6, not 3.5.x. 3.5.x will only receive bug fixes.

In deed, I guess I should have written 3.x to match the branch name.

Anyway, as stated in the PR, and after taking a look at the 3.x branch, it won't be backwards compatible. This part of the code was refactored between v3 and v4.

[Norrox]

To clarify, new features can only be backported to 3.6, not 3.5.x. 3.5.x will only receive bug fixes.

In deed, I guess I should have written 3.x to match the branch name.

Anyway, as stated in the PR, and after taking a look at the 3.x branch, it won't be backwards compatible. This part of the code was refactored between v3 and v4.

How is this coming along ? 🙂

[poirierlouis]

How is this coming along ? 🙂

No idea, last time I was working on this PR I did not have further feedback. Now it needs merge conflicts to be fixed and validation process to start anew I guess. I'll wake up this PR as soon as I get my hand back on Godot.