Re: Introducing transparent colors

> 2026/05/29 23:01、Yokota K. <[email protected]>のメール:
> 
> 
> 
>> 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.

I attach a patch against master.

The additional solution upgrades ColorSet class to be ARGB based (32bit hex) and update the following functions to handle both 16bit and 32bit hexes:

	- rgbFromHexName(): 16bit or 32bit hex -> RGBColor
	- getX11HexName(): (32bit ColorSet database) -> 16bit hex
	- getAllX11HexNames(): (32bit ColorSet database) -> pair of 16bit hex
	- setColor(): 16bit or 32bit hex -> (32bit ColorSet database)

In the above functions, 16bit hex and RGBColor parts (esp. LaTeX-related) are not changed so they can be used as the same as before. 16bit colors are simply treated as solid colors in the 32bit color scheme.

Also, following functions are newly introduced to interact in ARGB:

	- argbFromHexName(): 16bit or 32bit hex -> ARGBColor
	- get32bitHexName(): (32bit ColorSet database) -> 32bit hex
	- getAll32bitHexNames(): (32bit ColorSet database) -> pair of 32bit hex

I think the above lists up all the interactions with the ColorSet database.

As far as I tested, it looks working fine.

Koji



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