Am Montag, dem 25.01.2021 um 13:45 +0100 schrieb Jean-Marc Lasgouttes: > 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?
This is all fine as long as we can use semantic colors in the document as much as we can. I.e., only write static colors to the document if absolutely necessary. For branch, I'd like to enhance the color interface in a way that encourages people to assign a semantic color rather than setting a static color value (due to themeability). Same for customizable text colors (due to proper semantic markup). So if these rgb triplet is just used internally in these cases, I am fine with it. If BufferParams need to read and write them, I am opposed. Jürgen
signature.asc
Description: This is a digitally signed message part
-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
