Re: Introducing transparent colors

> 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.

Koji

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