Jean-Marc Lasgouttes wrote:
> However, I do not understand the logic between the getLyXName()
> behaviour.
Between the getLyXName() behaviour and what else?
Do you mean 'Behind' rather than 'Between'?
Assuming that you do:
> After my patch, it reads:
>
> LColor::color LColor::getFromLyXName(string const & lyxname) const
> {
> string const lcname = ascii_lowercase(lyxname);
> if (pimpl_->transform.find(lcname) == pimpl_->transform.end()) {
> lyxerr << "LColor::getFromLyXName: Unknown color \""
> << lyxname << '"' << endl;
> addColor(static_cast<color>(pimpl_->infotab.size()),
> lcname);
> }
>
> return static_cast<LColor::color>(pimpl_->transform[lcname]);
> }
>
>
> I really do not understand why the call to addColor has been added.
> Its effect is that, if I put a bogus 'Color "foo"' statement in a
> layout file, instead of correctly falling back to "none" or
> something, the code will create a new color "foo" which is not bound
> to anything useful, and will create havoc later.
>
> Angus, Martin, I see that these changes were related to the branches
> work. Could you tell me what it is good for?
Branches can define arbitrary new colours as their background colour.
I believe that the same mechanism can also be used to add arbitrary
character colours also.
So, getFromLyXName is simply adding a new entry to the
map<name, #rrggbb> used to store these colours. What is so confusing
about that?
--
Angus
