Improve ColorPicker picker shape keyboard and joypad accessibility

[FeniXb3]

While experimenting with accessibility, I realized that ColorPicker does not allow you to move the picker cursor around the color rectangle/wheel with keyboard or joypad (and I needed it, as it's the only part of ColorPicker that I want to show).

This PR implements:

• ability of both parts of picker shape to grab focus,
• setting picker focus StyleBox in theme,
• modifying picker cursor position with keyboard or joypad,
• keeping focus on proper control while changing picker shape,
• automatic focusing on the picker shape if it is visible and the HTML LineEdit is not visible (as it's what is currently being focused by default).

How it works in game and in the editor:

ColorPicker.keyaboard.and.joypad.game.mp4

ColorPicker.keyboard.editor.mp4

I don't really like how it works with the controller, as I'm using gui_input to check for actions and the controller does not send echo events, but it's possible to use the controller at least.

[fire]

I support this usability improvement in the proposal design, but it needs technical review.

[Calinou]

I don't really like how it works with the controller, as I'm using gui_input to check for actions and the controller does not send echo events, but it's possible to use the controller at least.

We should make the controller send fake echo events in this case, so that various GUI nodes can handle these directly. However, this should also be done in a way that doesn't affect existing game logic, which is going to be difficult to handle. Perhaps this should only be done for the built-in actions (those starting with ui_)?

Edit: Proposal opened:

• Make gamepads send echo events for UI navigation purposes godot-proposals#11199

[Calinou]

Tested locally, it works as expected.

Some usability comments:

• The hue slider should go faster when you adjust it with the keyboard arrows or gamepad buttons. Compare its speed to the color value on the left:

color_value_vs_hue_slider.mp4

Ideally, the speed at which the hue is adjusted should match the color value on the left, which is probably 3× to 4× faster. This can be done by increasing the increment for each button press on the hue slider.

• When using a color picker with a wheel shape, moving upwards should "slide" along the circle when you've reached the top (same for any other edge):

color_value_wheel_slide.mp4

Right now, it stops so you need to manually move to the left then move back up again.

[Calinou]

We should be able to draw a special circle focus stylebox (using a dedicated StyleBoxFlat in the editor theme/default project theme), so it matches the wheel's shape. This can be left for a future PR as it's not essential.

[FeniXb3]

I modified the theme to have separate styleboxes - one for rectangle-shaped elements and another for circle-shaped elements:

[FeniXb3]

The hue slider should go faster when you adjust it with the keyboard arrows or gamepad buttons. Compare its speed to the color value on the left:

color_value_vs_hue_slider.mp4

Ideally, the speed at which the hue is adjusted should match the color value on the left, which is probably 3× to 4× faster. This can be done by increasing the increment for each button press on the hue slider.

The hue slider goes exactly 3.6× slower than value slider in another shape, so your estimations were pretty correct. ^^ It is by design - value and saturation have values 0-100, but hue has values from range 0-360. Making each button press to increase hue in bigger increments always would miss some values. But I added a multiplier if the event is echo, so after few repetions it speeds up. But again, as for now it does not affect controllers.

What I'm wondering now is if we should have it configurable in the editor, both for games and for ColorPickers in the editor somehow (in editor settings?). What do you think @Calinou ?

When using a color picker with a wheel shape, moving upwards should "slide" along the circle when you've reached the top (same for any other edge):

color_value_wheel_slide.mp4

Right now, it stops so you need to manually move to the left then move back up again.

Fixed, please check it now:

Nagrywanie.ekranu.2024-11-28.163308.mp4

I thought about making the cursor to spin around on the edge if you keep holding the same button, but while it went well for the HSV Wheel shape, it was buggy for both Circle shapes, so I stashed it for now. This is how it looked for HSV Wheel:

Nagrywanie.ekranu.2024-11-28.160945.mp4

I am not sure if it is worth to try implementing it well for all Circle shapes or skip it, as I don't know if anyone will take advantage of this feature.

[Calinou]

What I'm wondering now is if we should have it configurable in the editor, both for games and for ColorPickers in the editor somehow (in editor settings?). What do you think @Calinou ?

This would be a pretty niche option, so I'd focus on picking a good default instead.

[KoBeWi]

#82979 could be used for better joypad navigation if it was merged. For now the only way is implement the behavior using NOTIFICATION_PROCESS manually, like it was done in Slider for example.

Though the joypad navigation is a bit janky right now. When you enter the main color box, the only way out is either accepting or canceling; you can no longer select another element. There could be 2 focus modes here: one for navigating the elements and one for changing colors using the elements. You could switch them with accept/cancel. We have that in LineEdit.
Though it's something that can be added later.

[KoBeWi]

The wheel is difficult to use.

You need to press the direction depending on the current rotation. It would be easier if you could press a button to start moving and then it would rotate as long as it's still pressed, without needing to press other buttons.

[KoBeWi]

Unused.

[KoBeWi]

Can't you use wheel_uv for that?

[FeniXb3]

In one moment I did. But it meant that I had to add logic for navigating between two focus modes for this control, capturing next/prev actions, because wheel_uv would be used to handle focus for both parts of HSV Wheel.

It added more complexity to the class that is already overloaded with a lot of ifs and was not working well always (like it was sometimes looping focus between those two states when holding ui_focus_prev action instead of leaving the control and switching to the hex LineEdit. I thought that adding another control for both drawing the focus stylebox and making switching focus more reliable is a better choice.

If it's better to have few more ifs than using this empty control, I can work on it again.

[KoBeWi]

#99515 makes the code cleaner.
If your PR happens to be merged first, I'll simplify it and integrate with my changes.

[FeniXb3]

I changed the code to not use a dedicated new Control for handling focus of wheel in HSV Wheel shape. Now the wheel control can grab focus in this shape, while focus stylebox is drawn on wheel_uv. I had whith wheel_uv handling everything and working well with ui_focus_prev and ui_focus_next, but it ui_up was glitching and I choose approach that seemed to work always with some tweaks, without introducing a new control.

[KoBeWi]

What does HACK refer to? Vector2i() is initial value of the cursor vector, so it needs to be initialized. Not sure what the other condition is for, it can be safely removed it seems.

[FeniXb3]

At first, I wanted to save the cursor position calculated in _hsv_draw and use it in _uv_input, but the cursor was moving in strange directions, as I mentioned in another comment. I checked if calculating it here every time would fix the issue, but it didn't. That's why I decided to calculate it only if it was not set (or was reset by clicking with mouse) and this is what the hack refers to, as it is not the way I think it should be done, but it does not seem to work well with the correct way. I might

Not sure what the other condition is for, it can be safely removed it seems.

I added it when I was working on sliding along the edge of the circle when you keep pressing any direction. But it seems it is not needed now. Removed.

[KoBeWi]

A way to not use it is keeping the variable local in _uv_input(), which means calculating sin/cos again every time.

[FeniXb3]

The hack mentioned in another place is connected with issues with calculating sin/cos again every time. I tried it at the beginning and it's behaviour was strange - the cursor was not going in straight lines. I believe it might be caused by some precision loss while calculating this, or something like that.

I realized that even when you drag the cursor with mouse, the offset of it's center and the mouse cursor is changing, depending on how high or low on the circle you are. You can see that on this video:

Nagrywanie.ekranu.2024-12-09.091855.mp4

[FeniXb3]

#82979 could be used for better joypad navigation if it was merged. For now the only way is implement the behavior using NOTIFICATION_PROCESS manually, like it was done in Slider for example.

I did it like in Slider, thanks for the suggestion. I tried with get_vector in NOTIFICATION_INTERNAL_PROCESS before, but it was not working. Now I see that I might have missed calling set_process_internal(true) in the right moment.

Though the joypad navigation is a bit janky right now. When you enter the main color box, the only way out is either accepting or canceling; you can no longer select another element. There could be 2 focus modes here: one for navigating the elements and one for changing colors using the elements. You could switch them with accept/cancel. We have that in LineEdit. Though it's something that can be added later.

I added this second focus mode like in LineEdit. I thought about it before, but I didn't see benefits in my usecase so I skipped it before. It works well, for both LineEdit and ColorPicker picker shapes now if you use a ColorPicker directly. But if you show it via ColorPickerButton, it failes in both cases. The reason is that both accept and cancel actions close the popup that ColorPicker is in. You can see the behaviour on this video:

2024-12-07.20-37-02.ColorPicker.shape.focus.like.LineEdit.mp4

I didn't bother to implement this as I use focus next/prev actions to navigate through ColorPicker's controls. I configured inputs for those actions to shoulder buttons and I was using them to test this feature. I forgot that by default there are no joypad buttons connected to those actions. Is there any reason this is not done by default? I wonder if I can simply configure them within this PR to make it work better out of the box.

The wheel is difficult to use. You need to press the direction depending on the current rotation. It would be easier if you could press a button to start moving and then it would rotate as long as it's still pressed, without needing to press other buttons.

Done. I had it stashed, as I mentioned in one of the previous comments here, as I wasn't sure if I should try and implement similar behaviour for both circle shapes. In the end I separated their behaviours.

[KoBeWi]

The reason is that both accept and cancel actions close the popup that ColorPicker is in.

You could try using accept_event() in the shape's gui input, to prevent the event from propagating.

[FeniXb3]

The reason is that both accept and cancel actions close the popup that ColorPicker is in.

You could try using accept_event() in the shape's gui input, to prevent the event from propagating.

I do. What I see now while debugging is that the ColorPickerPopupPanel::_input_from_window gets the input event before my gui_input handler so the accept_event() don't do much in this case. As tihs popup has no "OK" button, I can understand that accept action is a reasonable way to confirm the color choice,

[FeniXb3]

I believe the feature is done with suggestions applied, if I didn't miss something. I squashed all the commits already as well.

I attach a sample project to make it easier to test it. It has configured ui next and prev actions on controller shoulder buttons and accept/cancel on A/B buttons of Xbox controller.
godot-colorpicker-accessibility-test.zip

I believe those buttons should be configured in the InputMap by default, but I think it should be separate PR.

Is there anything else I should do?