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
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
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
J
>"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
mu
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
> 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 th
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
>>>
>>> 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_runni
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
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. Bu
> 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
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 "ev
>> 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 agai
[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
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 wh
"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 indicat
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
p
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" <[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 an
>> 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:
> 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
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 t
>>> 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
"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 different
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 th
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 gmane.editors.l
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
> C
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:
> 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:
> I almost forgot:
>
> - adding Accept/Reject to the context menu at the location of a change.
very good idea
pavel
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 pa
>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
>> 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 insid
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 w
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 muc
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 (se
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 a
40 matches
Mail list logo
