Richard Heck wrote:
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.
OK, thanks.
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?
The color cache is not something that changes, it is just a gateway
between LyX colors and Qt colors. So I think this is not related to this
problem.
Or
is it that the QPrefsDialog is being initialized the first time
Tools>Preferences is called and not re-initialized on subsequent calls?
That could be a problem indeed. Any initialisation shall be done in
initParam(), if some initialisation is done in the constructor, that
shall be transfered in there.
Abdel.
