Andre Poenitz schreef:
On Sun, Feb 08, 2009 at 03:49:49AM +0100, Vincent van Ravesteijn wrote:
OK ?
I am a bit concerned about the includes, but I think that can be handled
later by something like the attached patch (untested).
These includes are simply a result of the fact that I
On Sun, Feb 08, 2009 at 03:49:49AM +0100, Vincent van Ravesteijn wrote:
> OK ?
I am a bit concerned about the includes, but I think that can be handled
later by something like the attached patch (untested).
Andre'
Index: Color.h
===
Final patches (I hope).
Patch 1:
*Color.cpp/h: add new Color class
*ColorCache.cpp/h: add code to convert Color to QColor
Patch 2:
* rowpainter.cpp: now the color for painting selected text and changed
text is set via FontInfo::setColor. However, this color should remain a
ColorCode as this co
On Thu, Jan 15, 2009 at 08:59:34AM +0100, Jean-Marc Lasgouttes wrote:
> I thought it was done by some templates, but now I cannot find them.
> Forget that for now.
It's in std::rel_ops in
But they tend to create more trouble than benefit.
Andre'
Le 14 janv. 09 à 23:19, Vincent van Ravesteijn a écrit :
Done. The nice thing is that we can now also make a new color:
Color_deletedtextmodifier. This can be set by the user to specify
the degree of lightening or darkening of the color. It would be
nice if the user can also put this to Colo
If I can go through with this, I would like to have a few OKs, because
changing all ColorCode's in the sources to Color is a quite intrusive
operation.
Yes, though that sort of sed-patch can often be committed separately,
for the most part, and it's usually fairly safe, in the sense that, if
Jean-Marc Lasgouttes schreef:
I created a new class ColorCode (and renamed the old enum to
something else).
Why not Color?
I moved this class to Color.cpp and renamed it to Color.
You could remove this type and set mergecolor to Color_ignore when no
merging is required (would b
