Vincent van Ravesteijn - TNW wrote:
So, if you don't have any more comments, then I'll change the two
initializations and send you a new patch this evening.
Please do. I like this patch.
Jmarc
Here it is.
There is only one line that is changed.
Vincent
JMarc, do you have
Pavel Sanda [EMAIL PROTECTED] writes:
JMarc, do you have some more comments on this or should it go in?
Please put it in, I am busy atm.
JMarc
Jean-Marc Lasgouttes wrote:
Pavel Sanda [EMAIL PROTECTED] writes:
JMarc, do you have some more comments on this or should it go in?
Please put it in, I am busy atm.
i gave it short test and seems to work, so now its in. Vincent, you probably
want to add something to 'news in 1.6' wiki.
Vincent van Ravesteijn - TNW wrote:
> >> So, if you don't have any more comments, then I'll change the two
> >> initializations and send you a new patch this evening.
> >
> >Please do. I like this patch.
> >
> >Jmarc
>
>
> Here it is.
>
> There is only one line that is changed.
>
> Vincent
Pavel Sanda <[EMAIL PROTECTED]> writes:
> JMarc, do you have some more comments on this or should it go in?
Please put it in, I am busy atm.
JMarc
Jean-Marc Lasgouttes wrote:
> Pavel Sanda <[EMAIL PROTECTED]> writes:
> > JMarc, do you have some more comments on this or should it go in?
>
> Please put it in, I am busy atm.
i gave it short test and seems to work, so now its in. Vincent, you probably
want to add something to 'news in 1.6'
Vincent van Ravesteijn [EMAIL PROTECTED] writes:
I have processed your comments. I also removed als Change::UNCHANGED
and friends from the code. I had to work with objects after all, due
to the Change::color function. If you like it, we might change it in
other parts of the code.
What s the
Vincent van Ravesteijn [EMAIL PROTECTED] writes:
I have processed your comments. I also removed als Change::UNCHANGED
and friends from the code. I had to work with objects after all,
due
to the Change::color function. If you like it, we might change it in
other parts of the code.
Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes:
So, if you don't have any more comments, then I'll change the two
initializations and send you a new patch this evening.
Please do. I like this patch.
JMarc
Vincent van Ravesteijn - TNW wrote:
Vincent van Ravesteijn [EMAIL PROTECTED] writes:
I have processed your comments. I also removed als Change::UNCHANGED
d friends from the code. I had to work with objects after all,
due
to the Change::color function. If you like it, we
Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes:
So, if you don't have any more comments, then I'll change the two
initializations and send you a new patch this evening.
Please do. I like this patch.
Jmarc
Here it is.
There is only one line that is changed.
Vincent
Vincent van Ravesteijn <[EMAIL PROTECTED]> writes:
> I have processed your comments. I also removed als Change::UNCHANGED
> and friends from the code. I had to work with objects after all, due
> to the Change::color function. If you like it, we might change it in
> other parts of the code.
What
> Vincent van Ravesteijn <[EMAIL PROTECTED]> writes:
> > I have processed your comments. I also removed als Change::UNCHANGED
> > and friends from the code. I had to work with objects after all,
due
> > to the Change::color function. If you like it, we might change it in
> > other parts of
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
> So, if you don't have any more comments, then I'll change the two
> initializations and send you a new patch this evening.
Please do. I like this patch.
JMarc
Vincent van Ravesteijn - TNW wrote:
Vincent van Ravesteijn <[EMAIL PROTECTED]> writes:
I have processed your comments. I also removed als Change::UNCHANGED
d friends from the code. I had to work with objects after all,
due
to the Change::color function. If you like it, we
>"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
>> So, if you don't have any more comments, then I'll change the two
>> initializations and send you a new patch this evening.
>
>Please do. I like this patch.
>
>Jmarc
Here it is.
There is only one line that is changed.
Vincent
On Sun, Sep 14, 2008 at 10:07:51PM +0200, Abdelrazak Younes wrote:
Vincent van Ravesteijn wrote:
Jean-Marc Lasgouttes wrote:
JMarc
Hi JMarc,
I have processed your comments. I also removed als Change::UNCHANGED
and friends from the code. I had to work with objects after all, due
to
Change change_running = Change() ;
change_running points to nothing valid.
Hm... not really.
The problem is that Change() is an rvalue that can't be bound
to an non-const reference (says the Standard, not MSVC...)
If it were written
Change const change_running = Change();
it
On Sun, Sep 14, 2008 at 10:07:51PM +0200, Abdelrazak Younes wrote:
> Vincent van Ravesteijn wrote:
>> Jean-Marc Lasgouttes wrote:
>>>
>>> JMarc
>>>
>>
>> Hi JMarc,
>>
>> I have processed your comments. I also removed als Change::UNCHANGED
>> and friends from the code. I had to work with objects
>>>
>>> Change & change_running = Change() ;
>>
>> change_running points to nothing valid.
>
> Hm... not really.
>
> The problem is that Change() is an rvalue that can't be bound
> to an non-const reference (says the Standard, not MSVC...)
>
> If it were written
>
> Change const &
On Wed, 10 Sep 2008, Vincent van Ravesteijn - TNW wrote:
what client you use?
Thought that would be obvious by now.. MS Outlook. I'm quite out of
options, other than installing Thunderbird.
Maybe it'd work better if you accessed the list through the news
interface, i.e. via
Christian Ridderström wrote:
On Wed, 10 Sep 2008, Vincent van Ravesteijn - TNW wrote:
what client you use?
Thought that would be obvious by now.. MS Outlook. I'm quite out of
options, other than installing Thunderbird.
Maybe it'd work better if you accessed the list through the news
Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes:
I added a static AuthorList::Color(int id) method in stead of a
Change::Color() method, because I feel that the AuthorList is deciding
on which author gets which id and thus which color. If you think it
should be done differently, I'm
I added a static AuthorList::Color(int id) method in stead of a
Change::Color() method, because I feel that the AuthorList is
deciding on which author gets which id and thus which color. If you
think it should be done differently, I'm sure you'll tell me and
I'll
change
it.
I still
Vincent van Ravesteijn - TNW wrote:
Yes, it's a general problem that I try to write patches that change the
least as possible, so you can easily review and understand the changes,
but this might introduce the 'errors' you mentioned. Moreover, I try to
do things the same as it is already done in
Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes:
Very good point, learning every every day.. I'll just move the code into
Change::color() .
(although I still feel that Change should not distribute color codes,
Why? Isn't it good encapsulation? The rowpainter code does not need to
know
Very good point,..
(although I still feel that Change should not distribute color codes,
Why? Isn't it good encapsulation? The rowpainter code does not need
to know how changes should look like
Yes, that's the very good point I refered to.
I meant the following:
Change::color() should
Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes:
Change::color() should indeed determine the color of a change. This
method then decides that we color the change according to the rank of
the author in the AuthorList. Then, it should ask AuthorList what the
rank is of the author and which
Getting into the philosophy department:
It can do that, but not expose it to the rowpainter code. The
rowpainter
does not care about the method used to pick a color.
but it is ok to expose that rowpainter should indicate a change by
painting it in a different color ? Even more striking,
Vincent van Ravesteijn - TNW wrote:
Getting into the philosophy department:
It can do that, but not expose it to the rowpainter code. The
rowpainter
does not care about the method used to pick a color.
but it is ok to expose that rowpainter should indicate a change by
Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes:
Following your reasoning, we should have a Change::paint(..) method, or
better, ChangeDeleted::paint(..) and ChangeAdded::paint(..), because
- we might not want to see deletions at all, or
- just paint it with a marker to indicate
Richard Heck wrote:
(hopefully, Jurgen, since he has done such a great job with
1.5---is that decided?).
Not yet, as far as I know. At the moment, I'm tempted to not say no, but
that does not mean that anyone else could step up -- s/he will certainly not
step on my toes (also, who knows what
[EMAIL PROTECTED] wrote:
Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes:
Following your reasoning, we should have a Change::paint(..) method, or
better, ChangeDeleted::paint(..) and ChangeAdded::paint(..), because
- we might not want to see deletions at all, or
- just paint it
This would be rather easy with changes-as-insets, but currently
changes are just like a font setting. So I doubt that we could go
painlessly to this level of generality.
I thought about mentioning this possibility, but didn't want to start
the everything's an inset war again. ;-)
rh
Vincent van Ravesteijn - TNW wrote:
This would be rather easy with changes-as-insets, but currently
changes are just like a font setting. So I doubt that we could go
painlessly to this level of generality.
I thought about mentioning this possibility, but didn't want to start
the
Note, for example, the weird things that happen with line width
when you have an open footnote at the end of a paragraph. I
really do not want to see that phenomenon with a deleted handful
of words. But if we could solve THAT problem, then that would
open up a lot of territory, I think.
On Wed, Sep 10, 2008 at 08:11:30PM +0200, Vincent van Ravesteijn - TNW wrote:
Note, for example, the weird things that happen with line width
when you have an open footnote at the end of a paragraph. I
really do not want to see that phenomenon with a deleted handful
of words. But if we
On Wed, 10 Sep 2008, Vincent van Ravesteijn - TNW wrote:
what client you use?
Thought that would be obvious by now.. MS Outlook. I'm quite out of
options, other than installing Thunderbird.
Maybe it'd work better if you accessed the list through the news
interface, i.e. via
Christian Ridderström wrote:
> On Wed, 10 Sep 2008, Vincent van Ravesteijn - TNW wrote:
>
>>> what client you use?
>>
>> Thought that would be obvious by now.. MS Outlook. I'm quite out of
>> options, other than installing Thunderbird.
>
> Maybe it'd work better if you accessed the list through
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
>> I added a static AuthorList::Color(int id) method in stead of a
>> Change::Color() method, because I feel that the AuthorList is deciding
>> on which author gets which id and thus which color. If you think it
>> should be done
>>> I added a static AuthorList::Color(int id) method in stead of a
>>> Change::Color() method, because I feel that the AuthorList is
>>> deciding on which author gets which id and thus which color. If you
>>> think it should be done differently, I'm sure you'll tell me and
I'll
>>> change
>>
Vincent van Ravesteijn - TNW wrote:
Yes, it's a general problem that I try to write patches that change the
least as possible, so you can easily review and understand the changes,
but this might introduce the 'errors' you mentioned. Moreover, I try to
do things the same as it is already done in
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
> Very good point, learning every every day.. I'll just move the code into
> Change::color() .
>
> (although I still feel that Change should not distribute color codes,
Why? Isn't it good encapsulation? The rowpainter code does not need
>> Very good point,..
>> (although I still feel that Change should not distribute color codes,
>
> Why? Isn't it good encapsulation? The rowpainter code does not need
> to know how changes should look like
Yes, that's the very good point I refered to.
I meant the following:
Change::color()
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
> Change::color() should indeed determine the color of a change. This
> method then decides that we color the change according to the rank of
> the author in the AuthorList. Then, it should ask AuthorList what the
> rank is of the author
Getting into the philosophy department:
> It can do that, but not expose it to the rowpainter code. The
rowpainter
> does not care about the method used to pick a color.
but it is ok to expose that rowpainter should indicate a change by
painting it in a different color ? Even more striking,
Vincent van Ravesteijn - TNW wrote:
Getting into the philosophy department:
It can do that, but not expose it to the rowpainter code. The
rowpainter
does not care about the method used to pick a color.
but it is ok to expose that rowpainter should indicate a change by
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
> Following your reasoning, we should have a Change::paint(..) method, or
> better, ChangeDeleted::paint(..) and ChangeAdded::paint(..), because
> - we might not want to see deletions at all, or
> - just paint it with a marker to
Richard Heck wrote:
> (hopefully, Jurgen, since he has done such a great job with
> 1.5---is that decided?).
Not yet, as far as I know. At the moment, I'm tempted to not say "no", but
that does not mean that anyone else could step up -- s/he will certainly not
step on my toes (also, who knows
[EMAIL PROTECTED] wrote:
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
Following your reasoning, we should have a Change::paint(..) method, or
better, ChangeDeleted::paint(..) and ChangeAdded::paint(..), because
- we might not want to see deletions at all, or
- just paint it
>> This would be rather easy with changes-as-insets, but currently
>> changes are just like a font setting. So I doubt that we could go
>> painlessly to this level of generality.
>>
>>
>I thought about mentioning this possibility, but didn't want to start
>the "everything's an inset" war
Vincent van Ravesteijn - TNW wrote:
This would be rather easy with changes-as-insets, but currently
changes are just like a font setting. So I doubt that we could go
painlessly to this level of generality.
I thought about mentioning this possibility, but didn't want to start
the
> Note, for example, the weird things that happen with line width
> when you have an open footnote at the end of a paragraph. I
> really do not want to see that phenomenon with a deleted handful
> of words. But if we could solve THAT problem, then that would
> open up a lot of territory, I
On Wed, Sep 10, 2008 at 08:11:30PM +0200, Vincent van Ravesteijn - TNW wrote:
>
> > Note, for example, the weird things that happen with line width
> > when you have an open footnote at the end of a paragraph. I
> > really do not want to see that phenomenon with a deleted handful
> > of words.
After complaints from a colleague that he couldn't see
which changes in a document were his and which were from
his supervisor, I implemented a slightly different way of
showing the changes.
A new patch.
I added a static AuthorList::Color(int id) method in stead of a
Change::Color()
Vincent van Ravesteijn - TNW wrote:
After complaints from a colleague that he couldn't see
which changes in a document were his and which were from
his supervisor, I implemented a slightly different way of
showing the changes.
A new patch.
I added a static AuthorList::Color(int
After complaints from a colleague that he couldn't see which changes
in a document were his and which were from his supervisor, I
implemented a slightly different way of showing the changes.
A new patch.
I added a static AuthorList::Color(int id) method in stead of a
Vincent van Ravesteijn - TNW wrote:
Thought that would be obvious by now.. MS Outlook. I'm quite out of
options, other than installing Thunderbird.
maybe outlook is afraid of .patch. what if attached as .txt?
pavel
> After complaints from a colleague that he couldn't see
> which changes in a document were his and which were from
> his supervisor, I implemented a slightly different way of
> showing the changes.
A new patch.
I added a static AuthorList::Color(int id) method in stead of a
Change::Color()
Vincent van Ravesteijn - TNW wrote:
> > After complaints from a colleague that he couldn't see
> > which changes in a document were his and which were from
> > his supervisor, I implemented a slightly different way of
> > showing the changes.
>
> A new patch.
>
> I added a static
> > After complaints from a colleague that he couldn't see which changes
> > in a document were his and which were from his supervisor, I
> > implemented a slightly different way of showing the changes.
>
> A new patch.
>
> I added a static AuthorList::Color(int id) method in stead of a
>
Vincent van Ravesteijn - TNW wrote:
> Thought that would be obvious by now.. MS Outlook. I'm quite out of
> options, other than installing Thunderbird.
maybe outlook is afraid of .patch. what if attached as .txt?
pavel
Jean-Marc Lasgouttes wrote:
Vincent van Ravesteijn - TNW[EMAIL PROTECTED] writes:
Hi all,
After complaints from a colleague that he couldn't see which changes in a
document were his and which were from his supervisor, I implemented a slightly
different way of showing the changes (see
On Saturday 06 September 2008 15:01:47 Abdelrazak Younes wrote:
I think this patch should be accepted as it implement a badly missing
feature for change-tracking and is very straight forward. And Vincent
fixed more bugs than any of us recently :-)
Anyone objects?
By the way Vincent, I much
On Sat, Sep 06, 2008 at 04:01:47PM +0200, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Vincent van Ravesteijn - TNW[EMAIL PROTECTED] writes:
Hi all,
After complaints from a colleague that he couldn't see which changes in a
document were his and which were from his
I think this patch should be accepted as it implement a badly missing
feature for change-tracking and is very straight forward. And Vincent fixed
more bugs than any of us recently :-)
By the way Vincent, I much say that I am impressed with how quick you
learned your way inside LyX
So, what has to be done before moving in the patch ? Some suggestions:
- I will add a Change::Color( ) method like JMarc suggested,
- I would like to remove the paragraph break of a deleted paragraph break
(IYKWIM), but this might not be that easy.
- The painting of a deleted open inset might
Vincent van Ravesteijn - TNW wrote:
Thank you guys, it is nice to hear that you appreciate my contributions.
So, what has to be done before moving in the patch ? Some suggestions:
- I will add a Change::Color( ) method like JMarc suggested,
better to decompose it to more subsequent
Vincent van Ravesteijn - TNW wrote:
I almost forgot:
- adding Accept/Reject to the context menu at the location of a change.
very good idea
pavel
Jean-Marc Lasgouttes wrote:
"Vincent van Ravesteijn - TNW"<[EMAIL PROTECTED]> writes:
Hi all,
After complaints from a colleague that he couldn't see which changes in a
document were his and which were from his supervisor, I implemented a slightly
different way of showing the changes
On Saturday 06 September 2008 15:01:47 Abdelrazak Younes wrote:
> I think this patch should be accepted as it implement a badly missing
> feature for change-tracking and is very straight forward. And Vincent
> fixed more bugs than any of us recently :-)
Anyone objects?
> By the way Vincent, I
On Sat, Sep 06, 2008 at 04:01:47PM +0200, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
> > "Vincent van Ravesteijn - TNW"<[EMAIL PROTECTED]> writes:
> >
> >
> >> Hi all,
> >>
> >> After complaints from a colleague that he couldn't see which changes in a
> >> document were his and
>> I think this patch should be accepted as it implement a badly missing
>> feature for change-tracking and is very straight forward. And Vincent fixed
>> more bugs than any of us recently :-)
>>
>> By the way Vincent, I much say that I am impressed with how quick you
>> learned your way
>So, what has to be done before moving in the patch ? Some suggestions:
>
>- I will add a Change::Color( ) method like JMarc suggested,
>
>- I would like to remove the paragraph break of a deleted paragraph break
>(IYKWIM), but this might not be that easy.
>
>- The painting of a deleted open
Vincent van Ravesteijn - TNW wrote:
> Thank you guys, it is nice to hear that you appreciate my contributions.
>
> So, what has to be done before moving in the patch ? Some suggestions:
> - I will add a Change::Color( ) method like JMarc suggested,
better to decompose it to more subsequent
Vincent van Ravesteijn - TNW wrote:
> I almost forgot:
>
> - adding Accept/Reject to the context menu at the location of a change.
very good idea
pavel
Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes:
Hi all,
After complaints from a colleague that he couldn't see which changes in a
document were his and which were from his supervisor, I implemented a
slightly different way of showing the changes (see png).
In the attached
Vincent van Ravesteijn - TNW wrote:
PS. Would it be best to open an enhancement bug for these kinds of things ?
i usually wait whether the issue falls asleep as with your svn-patch (what is
the status btw?),
then i put it into bugz.
btw while i was trying the patch i found that for completely
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
> Hi all,
>
> After complaints from a colleague that he couldn't see which changes in a
> document were his and which were from his supervisor, I implemented a
> slightly different way of showing the changes (see png).
>
> In the
Vincent van Ravesteijn - TNW wrote:
> PS. Would it be best to open an enhancement bug for these kinds of things ?
i usually wait whether the issue falls asleep as with your svn-patch (what is
the status btw?),
then i put it into bugz.
btw while i was trying the patch i found that for completely
80 matches
Mail list logo
