Save color palette as resources to reuse later

[nongvantinh]

Close godotengine/godot-proposals#7946

The lack of a palette library slows down development time because swatches contain many colors that may not match the mood an artist is trying to achieve. This can hinder their workflow as they search for the right color within a large set of mostly irrelevant options.

Untitled.video.-.Made.with.Clipchamp.mp4

[RedMser]

Suggested change

	save_swatches->set_tooltip_text("Save the current color palette to reuse latter");
	save_swatches->set_tooltip_text("Save the current color palette to reuse later");

[RedMser]

Also for translatable text you should use translation macros like TTR or RTR.

[RedMser]

Must #ifdef for TOOLS_ENABLED. Though ideally, the saving and loading palette feature should also work when using the ColorPicker in a game/application project. Possibly with a boolean flag to enable or disable this feature.

[AThousandShips]

This should use icons available at runtime, not editor icons, there are some appropriate ones available, and otherwise they should be added, this shouldn't depend on the editor

[fire]

I approve of allowing saving the color pallete from a usability team perspective.

[nongvantinh]

Update:

• Use FileDialog instead of EditorFileDialog.
• Save the palette in the user:// path instead of placing it in the project folder.
• Remove the Palette resource class because it doesn't need anymore.

@AThousandShips What do you mean when you say use icons available at runtime? I couldn't find the correct function to call.

[AThousandShips]

Icons available at runtime are those which aren't editor specific, meant in running projects not running the program itself sorry for confusion

Accidental approval

[nongvantinh]

Sorry for the annoying force push. I wasn't familiar with the TTR part. I need one more favor. I couldn't find the correct icon to use in the function get_theme_icon.

[AThousandShips]

If it isn't in the default theme scene/theme/icons/ then you can add them from the editor or create new ones, and then you need to add them to the default theme, see in scene/theme/default_theme.cpp for details

But I think the normal folder icon is sufficient

Gonna test this one probably tomorrow but code looks good, got some final remarks I'll add when I've tested it out

[Calinou]

I wonder if it should be possible to give a name to each color, and have the name displayed in a tooltip when hovering the color in the ColorPicker's swatch list.

It's common for designers to assign names to colors to make slightly different colors easier to distinguish from each other, or even to refer to them in natural language. If I refer to "lime 800" from Tailwind's color palette, you can immediately know it's #3f6212.

This could be left to a future PR, but we should make sure this feature can be implemented in the future without breaking compatibility (i.e. without changing the data structure in the resource).

[AThousandShips]

Tested and it works as expected, however I don't think the list of resources allowed makes sense, it should probably just limit to res and tres because it currently allows you to save as things like animtex and mesh, which don't make sense

Edit: correction, it shouldn't even be that, it should be some binary format dedicated to this, it doesn't actually store a res or tres file either, so that needs to be fixed

[Calinou]

I suggest using ConfigFile to save palettes as opposed to FileAccess, so you have a text format that is friendly to version control. I'd also give them a custom file extension so they can be targeted more specifically, e.g. cpl.

A similar approach is used for script editor syntax themes, which use a tet file extension.

[KoBeWi]

When there are no colors to save, the menu has wrong size:

Using Quick Load at runtime causes crash.

Palettes are saved as .res by default. I think .tres is more suited; it's better to save small resources as text.
Also I'd rename Palette to ColorPalette.

If you expose a new class, you need to run doctool and fill the generated XML file.

[KoBeWi]

You can't include editor code in scene/ files. You'll need to find a way to use quick open without the dependency (maybe it can be handled by parent node and a callback).

[nongvantinh]

The quickloading option should not appear when running the app; it is only available in the editor.

Quick loading is only supported in the editor. Therefore, if I add this option to the ColorPicker, users will be aware of its availability. However, when they use the ColorPicker in their games, they will notice that the quickloading feature is missing, causing a discrepancy in workflow.

I am unsure whether to remove it entirely or implement a QuickOpenDialog that supports both the editor and in-game instances. Do you have any opinions on this?

[KoBeWi]

The quickloading option should not appear when running the app; it is only available in the editor.

But it does appear and causes a crash. It's fine if it would be only in the editor. If you want to get rid of the editor dependency, you could add an unexposed method set_quick_open_callback(), which would be a Callable set by the editor (there is a convenient setup_color_picker() method in EditorNode). When this callable is set, the ColorPicker would display the Quick Open option and selecting it would run the callback.

[nongvantinh]

Ops, I messed up git history again.