Re: Introducing transparent colors

> 2026/05/27 21:33、Yokota K. <[email protected]>のメール:
> 
> 
> 
>> 2026/05/20 20:50、Koji Yokota <[email protected]>のメール:
>> 
>>> 2026/05/18 22:10、Jean-Marc Lasgouttes <[email protected]>のメール:
>>> 
>>> I welcome proper support for transparent colors, although we will have to check that our drawing mechanism is ready for it. I suspect that there are some implicit assumptions of opacity here and there.
>> 
>> I understand the concern about the risk. The only entrance to RGBA-related representation is via 9-chars ARGB strings (#AARRGGBB) given by QColor::name(QColor::HexArgb) in GuiPrefs.cpp. The user’s theme color settings come in here. Then modified Color::rgbFromHexName() converts it to RGBAColor class, a subclass of GBAColor.
>> 
>> Modified Color::X11hexname() can output 9-chars ARGB strings when arg is RGBAColor class but it is limited to UI theme colors, since other colors will not be represented by RGBAColor.
>> 
>> So it forms a closed system like:
>> 
>>        Color setting in Preferences
>>                      |
>>                 (QColor::name)
>>                      |
>>                      V
>>                  #AARRGGBB ——— Color::rgbFromHexName() ——> RGBAColor (RGBColor
>>                      ^                                        |       subclass)
>>                      |———————— Color::X11hexname() <———————————
>> 
>> Existing functions use the base class RGBColor so they are not affected.
>> 
>> # BTW I should rename the RGBAColor struct to ARGBColor.
>> 
>>> For you preedit needs, are you aware of the mergeColor mechanism in the Color class? I understand it is a kludge, though.
>> 
>> Thank you for the information. I haven’t checked it but it can be an alternative if the above doesn’t go well.
> 
> If there is no objection, I’m going ahead with ARGBColor. It can use a ready-made color dialog so we can refrain from setting up a customized switch in UI for the interpretation of white between transparency and solid white.

This works fine once color theme is loaded, but this causes the initial color UI to be slightly different from the one after the default theme is clicked when it has transparent colors, since the former is ARGB whereas the latter is RGB.

To remove this inconsistency, ColorSet class needs to be changed to ARGB based. Then the change is propagated to functions that call ColorSet::getX11HexName() that may implicitly assume #RRGGBB. There are multiple places where this function is called but the problem seems to be confined to this point. I’m going to check whether they are handleable.

Koji

-- 
lyx-devel mailing list
[email protected]
https://lists.lyx.org/mailman/listinfo/lyx-devel