[LyX/master] Prevent branch background color from leaking out of the document

[Jean-Marc Lasgouttes]

Le 22/01/2021 à 11:12, Jürgen Spitzmüller a écrit :
>> My take is that the name is only needed for the colors of GUI
>> elements
>> that can be set in the color preferences.
> 
> What about the colors set in document settings (branch background,
> greyedouttext, box background, index labels)?

So, I have been doing some reading of the code, which obviously help 
discussion.

There are 3 notions of colors:

* ColorCode is an enum, used in FontInfo. This is nice in particular for 
the GUI, but not for using colors in documents, where we are limited to 
an arbitrary list of colors. A ColorCode can be bound to any RGB color.

* Color is is a weird class that replaces somehow transparency, by 
specifying a merge color and a base color and then computing a mix of 
them (not sure whether doing the fusion in RGB space is the right thing 
to do, but it is what it is). Actually, FontInfo uses a ColorCode enum 
_and_ a Color object :-/

* RGBColor is used for elements that should have a color particular to 
the document. It is defined by (r,g,b) components, but to be used, it is 
necessary to give them a name, and then to ask ColorSet to allocate a 
ColorCode to them. Indeed, the only interface that the frontend 
understands is the ColorCode (or Color pair).


What I propose (not 2.4 business IMO) is

* when e.g. the BranchList object requires a color, it can just give a 
rgb triplet and require a color code. The name is just an intermediate 
valuethat is of no use. If the code requests ColorCode ids when needed, 
there is no issue of per-document colors. The downside is that a 
long-running LyX session could have a complexity issue (?).

* similarly in Buffer params, the code can request a ColorCode for each 
customizable color and set it to the RGB value read from the LyX file.

* Maybe get rid of Color class: it can be nicely represented by an int, like
   base_color + (1 << 16) * merge_color
If not doing that, then we could use always a Color object in places 
where a ColorCode is currently used.

Better now?
JMarc