Abdelrazak Younes wrote:
> Richard Heck wrote:
>> The issue was that the newcolors_ were being checked against prefcolors_
>> to make sure the color had changed, but prefcolors_ contained the colors
>> from the preferences file and was not updated when changes were made.
>> Hence any attempt to revert to the original color was ignored. The
>> obvious thing to do is:
>> prefcolors_ = newcolors_
>> after colors are updated in apply(). As things were, this doesn't
>> work because apply() is const. So we make prefcolors_ mutable.
>>
>> I've also renamed prefcolors_ to oldcolors_, as is more compatible with
>> its new purpose.
> OK, looks good. But I don't understand why it worked before for other
> colors than black...
Because black was the default for foreground. Hence the test
if (prefcolors_[i]!=newcolors_[i])
would fail: prefcolors_[LColor::foreground] is black (or 0x0, or however
that is stored). You can confirm this by doing exactly the same sequence
of things with, say, the note background color: You can change it, but
once you do you can't change it back, though you can change it to
anything else you like.
There is one thing that puzzles me here. The code that sets prefcolors_
(now oldcolors_) is in the PrefColors constructor, and it gets its
settings from guiApp->color_cache_. So maybe the real problem is that
the color cache isn't being updated as the colors on screen change? Or
is it that the QPrefsDialog is being initialized the first time
Tools>Preferences is called and not re-initialized on subsequent calls?
Richard
--
==================================================================
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==================================================================
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
