Vincent van Ravesteijn wrote:
> Are these ok for branch ?
Yes, OK.
Jürgen
Jürgen Spitzmüller schreef:
Vincent van Ravesteijn wrote:
This patch got more and more complicated when trying to solve the
technical implementation (see thread on Merging Colors).
What is your opinion now ?
What are the remaining issues of the "merging colors" patch? AFAICS, there
w
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
Vincent van Ravesteijn schrieb:
The patch will be huge and I need to be very careful.
OK then better not before LyX 1.6.3. I'll test it as best as possible in the meantime because I have
to use change tracking quite often these days.
I will do it shortly, but I'm fixing some critical bugs
Uwe Stöhr schreef:
Vincent van Ravesteijn schrieb:
Otherwise I ask for an OK or comments for this patch.
Hello Vincent, what about your patch? When I remember correctly we
agreed to put it in for LyX 1.6.x and it was also requested in
bugzilla. Can you put it to trunk please?
Jürgen, am I
Vincent van Ravesteijn schrieb:
Otherwise I ask for an OK or comments for this patch.
Hello Vincent, what about your patch? When I remember correctly we agreed to put it in for LyX 1.6.x
and it was also requested in bugzilla. Can you put it to trunk please?
Jürgen, am I right? If so this sh
Vincent van Ravesteijn wrote:
> Yes, the last remarks of JMarc can be addressed quite easily.
>
> The risks I see is that I would have to change almost all ColorCode's in
> the code to Color objects. Every change or lack of change could possibly
> introduce a new bug.
If you think it's too risky,
Jürgen Spitzmüller schreef:
Vincent van Ravesteijn wrote:
This patch got more and more complicated when trying to solve the
technical implementation (see thread on Merging Colors).
What is your opinion now ?
What are the remaining issues of the "merging colors" patch? AFAICS, there
w
Vincent van Ravesteijn wrote:
> This patch got more and more complicated when trying to solve the
> technical implementation (see thread on Merging Colors).
>
> What is your opinion now ?
What are the remaining issues of the "merging colors" patch? AFAICS, there
were some final concerns by Jean-M
Jürgen Spitzmüller schreef:
Uwe Stöhr wrote:
Looks good, please put it in. This should in my opinion also go to LyX
1.6.2.
I agree (if the issues concerning the technical implementations are sorted
out).
Jürgen
This patch got more and more complicated when trying to solve the
te
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
Vincent van Ravesteijn writes:
> Herewith I'd like to propose a different solution. I'd like to hear
> whether this is a reasonable solution or not.
I am not sure that I prefer it to my solution, but I could live with it.
>I created a new class ColorCode (and renamed the old enum to
>som
Vincent van Ravesteijn wrote:
I like it, although I am not 100% sure from your screenshot that all
different pairs of colors can be
visually matched. And we have no idea of how color blind people
react to this.
What is probably strange is that the _deleted color will only be
available to th
I like it, although I am not 100% sure from your screenshot that all
different pairs of colors can be
visually matched. And we have no idea of how color blind people react
to this.
What is probably strange is that the _deleted color will only be
available to the user for changing when
has ac
Vincent van Ravesteijn wrote:
> While we are at the subject, I realized that the latex output with
> changes might be subject to change too.
>
> Do we want to exactly use the same colors in the output as on screen ?
Yes, why not.
> For now, the dvipost implementation of changes in the output is
>
While we are at the subject, I realized that the latex output with
changes might be subject to change too.
Do we want to exactly use the same colors in the output as on screen ?
For now, the dvipost implementation of changes in the output is
hardcoded as Red and Blue, can this be made any colo
Uwe Stöhr wrote:
> Looks good, please put it in. This should in my opinion also go to LyX
> 1.6.2.
I agree (if the issues concerning the technical implementations are sorted
out).
Jürgen
Vincent van Ravesteijn schrieb:
Here is a patch that lowers the saturation for deletions. It is also
possible to increase the saturation as shown in the attached.
Looks good, please put it in. This should in my opinion also go to LyX
1.6.2.
regards Uwe
Jean-Marc Lasgouttes schreef:
Le 28 déc. 08 à 01:47, Vincent van Ravesteijn a écrit :
Here is a patch that lowers the saturation for deletions. It is also
possible to increase the saturation as shown in the attached.
If there are strong opinions I'd like to hear them.
I like it, although I a
On 28/12/2008 12:50, Jean-Marc Lasgouttes wrote:
Le 28 déc. 08 à 01:47, Vincent van Ravesteijn a écrit :
Here is a patch that lowers the saturation for deletions. It is also
possible to increase the saturation as shown in the attached.
If there are strong opinions I'd like to hear them.
Look
Le 28 déc. 08 à 01:47, Vincent van Ravesteijn a écrit :
Here is a patch that lowers the saturation for deletions. It is
also possible to increase the saturation as shown in the attached.
If there are strong opinions I'd like to hear them.
I like it, although I am not 100% sure from your scre
> The only point I would put forward is to take care that saturation is not too
> low, for accessibility reasons.
if this turns out to be an issue we could always add the saturation level to
the preferences...
rgheck wrote:
> > Here is a patch that lowers the saturation for deletions. It is also
> > possible to increase the saturation as shown in the attached.
> >
> > If there are strong opinions I'd like to hear them.
> >
> > Otherwise I ask for an OK or comments for this patch.
>
> Looks good to me. I
Vincent van Ravesteijn wrote:
leuven edwin schreef:
I'm open for new ideas.
or lower the saturation for deletions as in attached
edwin
Here is a patch that lowers the saturation for deletions. It is also
possible to increase the saturation as shown in the attached.
If there are str
leuven edwin schreef:
I'm open for new ideas.
or lower the saturation for deletions as in attached
edwin
Here is a patch that lowers the saturation for deletions. It is also
possible to increase the saturation as shown in the attached.
If there are strong opinions I'd like to hear t
Richard Heck schreef:
Uwe Stöhr wrote:
leuven edwin schrieb:
or lower the saturation for deletions as in attached
This is a cool idea! This is perhaps the better solution.
I was about to suggest something similar. We need something that
scales, and this does.
rh
Yes, I had somewhat the
Uwe Stöhr wrote:
leuven edwin schrieb:
or lower the saturation for deletions as in attached
This is a cool idea! This is perhaps the better solution.
I was about to suggest something similar. We need something that scales,
and this does.
rh
leuven edwin schrieb:
or lower the saturation for deletions as in attached
This is a cool idea! This is perhaps the better solution.
best regards
Uwe
> I'm open for new ideas.
or lower the saturation for deletions as in attached
edwin
<>
Vincent van Ravesteijn schrieb:
You have just found a new feature in LyX. Each author has his own color
for the changes he made. Now, the addition and deletion is shown by
either a strike-through or an underline.
This is indeed a new feature I was not aware of. But anyway, having the same col
Uwe Stöhr schreef:
Today me was sent a larger file created with LyX 1.5.x with change
tracking enabled. When opening that file with LyX 1.6.1 every change
is highlighted in blue, no matter if it was a deletion or addition.
This make change tracking rather unusable.
In LyX 1.5.7 deletions are c
36 matches
Mail list logo
