Regression with gui_set_style in 5.5.0.3

[sshane]

when I do this:

DEFAULT_TEXT_COLOR = rl.WHITE
rl.gui_set_style(rl.GuiControl.DEFAULT, rl.GuiControlProperty.TEXT_COLOR_NORMAL, rl.color_to_int(DEFAULT_TEXT_COLOR))

I get this:

batman@workstation-shane:~/openpilot$ ./selfdrive/ui/ui.py 
RAYLIB STATIC 5.5.0.3 LOADED
Traceback (most recent call last):
  File "/home/batman/openpilot/./selfdrive/ui/ui.py", line 24, in <module>
    main()
  File "/home/batman/openpilot/./selfdrive/ui/ui.py", line 10, in main
    gui_app.init_window("UI")
  File "/home/batman/openpilot/openpilot/system/ui/lib/application.py", line 170, in init_window
    self._set_styles()
  File "/home/batman/openpilot/openpilot/system/ui/lib/application.py", line 347, in _set_styles
    rl.gui_set_style(rl.GuiControl.DEFAULT, rl.GuiControlProperty.TEXT_COLOR_NORMAL, rl.color_to_int(DEFAULT_TEXT_COLOR))
  File "/home/batman/openpilot/.venv/lib/python3.11/site-packages/pyray/__init__.py", line 94, in wrapped_func
    result = original_func(*args)
             ^^^^^^^^^^^^^^^^^^^^
OverflowError: can't convert negative number to unsigned

---

on 5.5.0.2 and 5.5.0.3 the input arguments are the same:

>>> print('params', rl.GuiControl.DEFAULT, rl.GuiControlProperty.TEXT_COLOR_NORMAL, rl.color_to_int(DEFAULT_TEXT_COLOR))
params 0 2 -1

Looks like it's this: #180

[electronstudio]

Style values are supposed to be unsigned ints, but prior to 5.5.0.3 there was a bug that they were treated as signed, forcing people to use various workarounds. So could be that you were using a workaround that is no longer necessary.

[electronstudio]

Or it could be that fixing this part of raygui broke something else that was dependent on the incorrect type.

[electronstudio]

I’m thinking the latter. Raygui is probably full of typing mistakes but gets away with them because as long as two types have the same number of bytes C doesn’t care. Meanwhile it’s a problem for strongly typed languages like Python because the FFI will default to attempting to convert the mismatched types.

[electronstudio]

Possible fix: we patch Raylib’s ColorToInt to return unsigned int. I worry that could break other things.

Possible fix: we add a function ColorToUnsignedInt and tell people to use that if they want something they can store in a raygui property. But then we’ve basically added another workaround when the original point was to remove a workaround.

[electronstudio]

Raylib’s ColorToInt returns signed int, but Raylib’s GetColor takes unsigned int! WTF. So I guess that means the two are already incompatible in Python, so we couldn’t make the situation any worse by patching it.

[sshane]

Yeah the two functions don't look compatible to me now. I haven't looked too deeply into this, but why did your PR change the int to unsigned when the raylib source is still signed?

https://github.com/raysan5/raylib/blob/ff8333435a787bd07aeaf9caafafa7d267f989fe/examples/shapes/raygui.h#L1560

GetColor, which is what this value is used in, also accepts signed integers, and returns the correct white color when passed -1:

https://github.com/raysan5/raylib/blob/ff8333435a787bd07aeaf9caafafa7d267f989fe/examples/shapes/raygui.h#L5525-L5535

[sshane]

Additionally, if you try to get around this by passing the unsigned version of -1, somewhere in Python/raylib, it tries to assume it's signed and won't fit:

rl.gui_set_style(rl.GuiControl.DEFAULT, rl.GuiControlProperty.TEXT_COLOR_NORMAL, _ct.c_uint32(4294967295).value)

Traceback (most recent call last):
  File "/home/batman/openpilot/.venv/lib/python3.11/site-packages/IPython/core/interactiveshell.py", line 3699, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-18-7f90ad91d64e>", line 1, in <module>
    rl.gui_set_style(rl.GuiControl.DEFAULT, rl.GuiControlProperty.TEXT_COLOR_NORMAL, _ct.c_uint32(-1).value)
  File "/home/batman/openpilot/.venv/lib/python3.11/site-packages/pyray/__init__.py", line 94, in wrapped_func
    result = original_func(*args)
             ^^^^^^^^^^^^^^^^^^^^
OverflowError: integer 4294967295 does not fit '32-bit int'

[electronstudio]

Yeah the two functions don't look compatible to me now. I haven't looked too deeply into this, but why did your PR change the int to unsigned when the raylib source is still signed?

Colors are 4 bytes, i.e. in hex 0x00000000 to 0xFFFFFFFF. The higher values can't be represented as signed 32 bit int as raygui.h purports to do. This was causing people to have to convert between signed and unsigned when they used gui_set_style and gui_get_style. By changing the C source to unsigned we fixed this. I've ported the only example I can find of Raygui set_style here: https://github.com/electronstudio/raylib-python-cffi/blob/master/examples/raygui/style_selector.py

It works when the colors are unsigned ints. It doesn't work with the return values of ColorToInt because they are signed.

GetColor is actually defined twice, once in raylib.h unsigned and once in raygui.h signed, so it's no wonder things are confused.

https://github.com/raysan5/raylib/blob/ff8333435a787bd07aeaf9caafafa7d267f989fe/examples/shapes/raygui.h#L1560

GetColor, which is what this value is used in, also accepts signed integers, and returns the correct white color when passed -1:

On my system the raylib.h definition takes priority over the raygui.h one and it doesn't accept -1.

https://github.com/raysan5/raylib/blob/ff8333435a787bd07aeaf9caafafa7d267f989fe/examples/shapes/raygui.h#L5525-L5535

(But if it did, how is -1 equivalent to white, i.e. 0xFFFFFFFF) ?

TLDR I think C doesn't do any unsigned / signed conversions so it doesn't matter if the function signatures are signed or unsigned and you can take what you get from ColorToInt and put it into GetColor with no problem. But Python will do conversions if there is a mismatch, which there is.

So I have patched ColorToInt to make it unsigned int. This works with my example, I just hope it doesn't break anything else.

[electronstudio]

I'm assuming the patch worked since have had no reports for 5.5.0.4.