> 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.
Koji
--
lyx-devel mailing list
[email protected]
https://lists.lyx.org/mailman/listinfo/lyx-devel
