Expose underlying components of UI elements such as ColorPicker

[torbenvanassche]

Describe the project you are working on

An RPG influenced game about a slime going on a journey.
This holds no relevance on the request though.

Describe the problem or limitation you are having in your project

It is currently not possible to use components from UI elements on their own in some cases.

f.e. this is the case with the ColorPicker UI element. It is currently only possible to create a full ColorPicker,
rather than a single color field with a color picker. (An example from the Unity Editor)

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

Exposing the color picker (this can be expanded to other UI elements as well) would allow for more compact customization of the user interface. Maybe the end user should not have all the options in the colorpicker, if we can use individual components rather than the colorpicker as a whole, we can finetune the UI more precisely for our specific usecase.

In addition to the color picker, being able to store swatches on their own would also be very nice (should I make a separate request for that?)

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

I would imagine, that this should be possible by having the elements that are used to build the ColorPicker be exposed to the scripting layer so we can work with them directly.

Logical events I would see for this colorpicker are OnColorPickingStart(), OnColorPickingEnd(), OnColorChange().

I could see an alternative solution to sample a pixel on the screen (with a Vector2 parameter) so we can sample a pixel at a location, if this is available, it gives me (us) everything we need to make this type of behaviour ourselves. Exposing the underlying components would however be preferable.

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

I don't think it can. The ColorPicker button itself is not available on its own. Technically, nothing impedes the functionality of the full suite color picker but in my opinion it could be rather bulky for the end user if all you want to do is pick a color.

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

I have not confirmed this, but I think the underlying components of the engine are exposed to the scripting layer. Which makes it difficult to implement.

[YuriSizov]

I'm not sure I understand which parts of the color picker you would want to reuse. The image that you have added to the proposal is exactly what you have in Godot as well. You have ColorPicker which is a popup, and you have ColotPickerButton, which is a button with a color preview that pops the ColorPicker.

So what exactly is missing for you? Do you want to reuse the color wheel perhaps?

[torbenvanassche]

im looking to have a way to sample the screen position essentially. Which doesn't appear to be available. At least I can't find it.
This would allow me to pick the color of something in code, so I can then do whatever I want with this data.

I want to use this to get information about color of an object without having to go through the colorpicker interface.
So that it can just be Color.Pick(Vector2(50, 50)) which then gives me the color value on the screen of the given Vector2

Edit: Probably some poor explanation on my part in the first message, appologies.
But also, yes. if it is possible to have the inidividual components of the color picker accessible it would allow for a greater degree of freedom in creating UI.

[YuriSizov]

So if you want to implement your own element that allows picking color from a screen coordinate, you can do it with DisplayServer.screen_get_pixel. This is what ColorPicker is using as well: godotengine/godot#74962

As for tearing the ColorPicker popup into reusable components, I agree that it would be a good idea so you can benefit from some of these pre-made widgets without all the complexity of the full popup.

[torbenvanassche]

That is entirely fair, thank you for referencing the method I could use for that. That resolves the feature request.

It would indeed be nice to see that change where the different building blocks of a predefined UI element are available for use so that we can customize UI to our hearts desire (while assuming the responsability of implementing the logic ourselves ofcourse) with the available signals to make it all work.

[KoBeWi]

ColorPicker has multiple properties that allow you to hide some of its elements. It's not possible to hide the color box, but you can hide everything else:

Though ColorPicker's components are just nodes, so you can hack it by accessing the pick button, reparenting it somewhere else and hiding the other parts manually.

[winston-yallow]

I agree this would be useful. I wanted to use the color wheel instead of the full picker in an App I made a while ago and had to reinvent the wheel (literally) 😁

Anyway, I had a look at the ColorPicker C++ implementation. At the moment the code is fairly intertwined, so we can't just expose the sub-widgets. Instead, the class would need to be split and refactored a bit so that the individual components can be exposed.

[torbenvanassche]

@KoBeWi while I agree that removing nodes from the scene that controls the color picker is an option. I do think there is a point to make for the QOL of having them available instead of walking backwards to remove parts the user doesn't need.