Lars Gullik Bjønnes wrote:
> I'd like Martin to test patch one, and commit that if it seems ok.
I'll commit it in a moment.
> Ad. patch2 I'd like to wait for 1.4.1 with that one.
OK.
Jürgen
On Mon, Jan 16, 2006 at 01:25:36PM +0100, Lars Gullik Bjønnes wrote:
> Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
>
> | Juergen Spitzmueller wrote:
> | > > > May I have the row-painter fix as a separate patch, please?
> | > Attached are the two fixes in separate patches.
> |
> | Comments?
>
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Juergen Spitzmueller wrote:
| > > > May I have the row-painter fix as a separate patch, please?
| > Attached are the two fixes in separate patches.
|
| Comments?
I'd like Martin to test patch one, and commit that if it seems ok.
Ad. patch2 I'd
Juergen Spitzmueller wrote:
> > > May I have the row-painter fix as a separate patch, please?
> Attached are the two fixes in separate patches.
Comments?
Jürgen
Can anyone confirm http://bugzilla.lyx.org/show_bug.cgi?id=2214 ? I
have checked that dvipost can overstrike formula and this is a
latex-generating problem of lyx.
Bo
Juergen Spitzmueller wrote:
> Lars Gullik Bjønnes wrote:
> > It changes some details that I am not sure will not have side-effects.
>
> I cannot exclude that in last consequence, of course, even if I've tested
> lots of possible cases. Maybe someone else could give it a hard test.
>
> > | > I think
Bo Peng wrote:
Could you please add it by yourself (http://bugzilla.lyx.org)? I feel a
little bit tired... :-)
Added, but I could not find your bug reports (in list all unconfirmed bugs).
Check for "NEW" bugs (I confirmed them). Or check for the latest bugs.
Or for component "change
Bo Peng wrote:
CAN NOT ACCEPT THE FIRST CHANGE (?)
1. open a lyx document
2. type in a, newline, b, newline
3. turn on change tracking
4. add change 1 after line b
5, add change 2 after line a
( get
a
change 2
b
change 1
)
6. Go to the beginning of the document, accept change, lyx wi
Bo Peng wrote:
Another one (hope it has not been reported)
CHANGE OF FORMULA IS NOT TRACED
1. open a lyx document
2. insert $x^2$
3. turn on change tracking
4. go into the formula and remove ^2
5. $x$ is not marked as changed.
Added to bugzilla.
Shall we advertise change-tracking in 1.4.
Another one (hope it has not been reported)
CHANGE OF FORMULA IS NOT TRACED
1. open a lyx document
2. insert $x^2$
3. turn on change tracking
4. go into the formula and remove ^2
5. $x$ is not marked as changed.
Shall we advertise change-tracking in 1.4.0 as experimental? I
understand 1.4.0 will
Another change tracking bug:
CAN NOT ACCEPT THE FIRST CHANGE (?)
1. open a lyx document
2. type in a, newline, b, newline
3. turn on change tracking
4. add change 1 after line b
5, add change 2 after line a
( get
a
change 2
b
change 1
)
6. Go to the beginning of the document
> >PASTED TEXT IS NOT CONSIDERED AS CHANGE
> >
> Very strange. I have added a bugzilla report...
This is not very strange in that the *not-changed property' of copied
lyx text is somehow preserved. If I paste from outside of lyx using my
middle button, the added text is considered as change.
Bo
Bo Peng wrote:
I am not sure whether or not this has been discussed, but I would like to add
PASTED TEXT IS NOT CONSIDERED AS CHANGE
1. new doc
2. write something, copy
3. turn on change tracking
4. paste
Very strange. I have added a bugzilla report...
Michael
> I have produced a set of test cases. I thought it might be better to
> send them to the mailing list before adding a couple of bugzilla entries.
I am not sure whether or not this has been discussed, but I would like to add
PASTED TEXT IS NOT CONSIDERED AS CHANGE
1. new doc
2. write something,
Juergen Spitzmueller wrote:
It is as simple as the attached. I've tested pretty intensive, some further
testing would be welcome, though.
Works like a charm! Lars?
Please also note my new bug reports #2202 and #2203. The first one is a
bit critical because LyX crashes (but this has nothing
Lars Gullik Bjønnes wrote:
> It changes some details that I am not sure will not have side-effects.
I cannot exclude that in last consequence, of course, even if I've tested
lots of possible cases. Maybe someone else could give it a hard test.
> | > I think this should wait so that it can get so
On Tue, Jan 10, 2006 at 12:13:31PM +0100, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
>
> > Now I am not sure anymore. Please test your patch also without the
> > rowpainter change and see if it works. endpos is *one past the end*,
> > i.e., the cursor is on the right side of all of the ro
Martin Vermeer wrote:
> Now I am not sure anymore. Please test your patch also without the
> rowpainter change and see if it works. endpos is *one past the end*,
> i.e., the cursor is on the right side of all of the row's characters. It
> shouldn't do any change tracking marking there.
It doesn't
On Tue, 2006-01-10 at 10:05 +0100, Juergen Spitzmueller wrote:
> Jean-Marc Lasgouttes wrote:
>
> > Juergen> It is as simple as the attached. I've tested pretty
> > Juergen> intensive, some further testing would be welcome, though.
> >
> > What does the rowpainter change do?
>
> Martin's latest r
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
|
| > I must admit that I find the patch not simple enough :-)
|
| Sure? I find it pretty straightforward.
It changes some details that I am not sure will not have side-effects.
| > I think this should wait so that i
Lars Gullik Bjønnes wrote:
> I must admit that I find the patch not simple enough :-)
Sure? I find it pretty straightforward.
> I think this should wait so that it can get some more testing first.
Your call of course.
Jürgen
Jean-Marc Lasgouttes wrote:
> Juergen> It is as simple as the attached. I've tested pretty
> Juergen> intensive, some further testing would be welcome, though.
>
> What does the rowpainter change do?
Martin's latest rowpainter change assures that rows are always repainted
because of change track
On Mon, Jan 09, 2006 at 04:51:41PM +0100, Jean-Marc Lasgouttes wrote:
> > "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
>
> Juergen> Lars Gullik Bjønnes wrote:
> >> | DELETE KEY DOES NOT MOVE THE CURSOR TO THE NEXT CHARACTER
> >>
> >> If this has a simple fix it should be done
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
|
| Juergen> Lars Gullik Bjønnes wrote:
| >> | DELETE KEY DOES NOT MOVE THE CURSOR TO THE NEXT CHARACTER
| >>
| >> If this has a simple fix it should be done, otherwise it shoul
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Lars Gullik Bjønnes wrote:
>> | DELETE KEY DOES NOT MOVE THE CURSOR TO THE NEXT CHARACTER
>>
>> If this has a simple fix it should be done, otherwise it should
>> wait.
Juergen> It is as simple as the attached. I've tes
Lars Gullik Bjønnes wrote:
> | DELETE KEY DOES NOT MOVE THE CURSOR TO THE NEXT CHARACTER
>
> If this has a simple fix it should be done, otherwise it should wait.
It is as simple as the attached. I've tested pretty intensive, some further
testing would be welcome, though.
Jürgen
Index: src/rowpa
On Mon, Jan 02, 2006 at 01:10:00AM +0100, Jean-Marc Lasgouttes wrote:
> | What is this a response to?
>
> >Your 'let's always repaint the row >with the cursor in it' patch I
> >belive.
>
> Right. My palm is not very good at
> quoting messages, sorry.
>
> JMarc
>
> --
> Lgb
For some reas
| What is this a response to?
>Your 'let's always repaint the row >with the cursor in it' patch I
>belive.
Right. My palm is not very good at
quoting messages, sorry.
JMarc
--
Lgb
On Sun, Jan 01, 2006 at 08:29:23PM +0100, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | On Sun, Jan 01, 2006 at 02:17:00PM +0100, [EMAIL PROTECTED] wrote:
> | > I cannot test it but it looks much
> | > better. I'd say 'apply it'.
> | >
> | > JMarc
> |
> | What is
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Sun, Jan 01, 2006 at 02:17:00PM +0100, [EMAIL PROTECTED] wrote:
| > I cannot test it but it looks much
| > better. I'd say 'apply it'.
| >
| > JMarc
|
| What is this a response to?
Your 'let's always repaint the row with the cursor in it' patch I
On Sun, Jan 01, 2006 at 02:17:00PM +0100, [EMAIL PROTECTED] wrote:
> I cannot test it but it looks much
> better. I'd say 'apply it'.
>
> JMarc
What is this a response to?
- Martin
pgpHQabjkkkCG.pgp
Description: PGP signature
On Sun, Jan 01, 2006 at 04:50:42PM +0100, Michael Gerz wrote:
> Martin Vermeer wrote:
>
> >If inserting newlines directly _were_ allowed, they would not be rolled
> >back together with the tracked changes to the surrounding characters. In
> >that sense change tracking would be inconsistent.
> >
>
Martin Vermeer wrote:
If inserting newlines directly _were_ allowed, they would not be rolled
back together with the tracked changes to the surrounding characters. In
that sense change tracking would be inconsistent.
Cutting and pasting selections subvert this scheme.
In other words: If inse
On Sun, Jan 01, 2006 at 03:40:34PM +0100, Michael Gerz wrote:
> Martin Vermeer wrote:
>
> >The code is here (text.C):
> >
> > 1026 void LyXText::breakParagraph(LCursor & cur, bool keep_layout)
> > 1027 {
> > 1028 BOOST_ASSERT(this == cur.text());
> > 1029 // allow only if at st
Martin Vermeer wrote:
The code is here (text.C):
1026 void LyXText::breakParagraph(LCursor & cur, bool keep_layout)
1027 {
1028 BOOST_ASSERT(this == cur.text());
1029 // allow only if at start or end, or all previous is new text
1030 Paragraph & cpar = cur.para
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Sun, Jan 01, 2006 at 02:00:58PM +0100, Michael Gerz wrote:
| > Michael Gerz wrote:
|
| ...
|
|
| > More investigation on paragraph breaks:
| >
| > Does not work: Pressing Enter in the middle of an unchanged line
| > Works: Selecting & copying
On Sun, Jan 01, 2006 at 02:00:58PM +0100, Michael Gerz wrote:
> Michael Gerz wrote:
...
> More investigation on paragraph breaks:
>
> Does not work: Pressing Enter in the middle of an unchanged line
> Works: Selecting & copying paragraph break, pasting it in the middle
> of an unchanged li
On Sun, Jan 01, 2006 at 02:00:58PM +0100, Michael Gerz wrote:
> Michael Gerz wrote:
>
> >Juergen Spitzmueller wrote:
> >
> >>My take on this is as follows: Fix the regressions that have been
> >>introduced by the rowSignature patch and leave all other things as
> >>they are. If we start to rewri
I cannot test it but it looks much
better. I'd say 'apply it'.
JMarc
Martin Vermeer wrote:
Actually I'd prefer to commit the attached. It is more general in that
it *always* repaints the row that the cursor is on, whether directly, or
in some inset. So I modified the cursor position test routine, achieving
a simplification too.
Tested and appears to work as well
Michael Gerz wrote:
Juergen Spitzmueller wrote:
My take on this is as follows: Fix the regressions that have been
introduced by the rowSignature patch and leave all other things as
they are. If we start to rewrite the change tracker code now (and
things like paragraph split/merge will need a
On Sun, Jan 01, 2006 at 03:25:31AM +0100, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> | I'll commit the isChanged version if no-one objects. Verified that it
> | does the job for both deletions and insertions.
>
> Ok, with me.
Actually I'd prefer to commit th
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Sat, Dec 31, 2005 at 07:40:40PM +0200, Martin Vermeer wrote:
| > On Sat, Dec 31, 2005 at 05:51:47PM +0100, Lars Gullik Bjønnes wrote:
| > > Martin Vermeer <[EMAIL PROTECTED]> writes:
| > >
| > > | Index: rowpainter.C
| > > |
On Sat, Dec 31, 2005 at 07:40:40PM +0200, Martin Vermeer wrote:
> On Sat, Dec 31, 2005 at 05:51:47PM +0100, Lars Gullik Bjønnes wrote:
> > Martin Vermeer <[EMAIL PROTECTED]> writes:
> >
> > | Index: rowpainter.C
> > | ===
> > | RCS fi
On Sat, Dec 31, 2005 at 05:51:47PM +0100, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | Index: rowpainter.C
> | ===
> | RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v
> | retrieving revis
Martin Vermeer <[EMAIL PROTECTED]> writes:
| Index: rowpainter.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v
| retrieving revision 1.161
| diff -u -p -r1.161 rowpainter.C
| --- rowpainter.C 30 Dec 2005 1
On Sat, Dec 31, 2005 at 04:34:35PM +0100, Michael Gerz wrote:
> Lars Gullik Bjønnes wrote:
>
> >Actually I think the simple solution for now is to use
> >
> >Changes::isChange on the row range, and if we have a change, just repaint
> >the row always.
> >
> >This can be accessed through Paragraph:
On Sat, Dec 31, 2005 at 02:47:21PM +0100, Michael Gerz wrote:
> John C. McCabe-Dansted wrote:
>
> >On Sunday 01 January 2006 01:15, Michael Gerz wrote:
> >
> >
> >>SCREEN IS NOT UPDATED AFTER DELETION
> >>
> >>1. New doc
> >>2. Enter "hello"
> >>3. Activate change tracking
> >>4. Place cursor in
Juergen Spitzmueller wrote:
My take on this is as follows: Fix the regressions that have been introduced
by the rowSignature patch and leave all other things as they are. If we start
to rewrite the change tracker code now (and things like paragraph split/merge
will need a major rewrite), we'll
Lars Gullik Bjønnes wrote:
Actually I think the simple solution for now is to use
Changes::isChange on the row range, and if we have a change, just repaint the
row always.
This can be accessed through Paragraph::isChanged.
So in rowpainter.C: paintPar:
If you do this manually, is the repain
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Michael Gerz <[EMAIL PROTECTED]> writes:
|
| | John C. McCabe-Dansted wrote:
| |
| | >On Sunday 01 January 2006 01:15, Michael Gerz wrote:
| | >
| | >>SCREEN IS NOT UPDATED AFTER DELETION
| | >>
| | >> 1. New doc
| | >> 2. Enter "hello"
| | >> 3.
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Michael Gerz wrote:
| > I am still wondering why the user has to accept all changes before he is
| > allowed to deactivate change tracking.
| > - If there is a technical reason for it, then the scenrio above will
| > cause trouble sooner or later
Michael Gerz wrote:
> I am still wondering why the user has to accept all changes before he is
> allowed to deactivate change tracking.
> - If there is a technical reason for it, then the scenrio above will
> cause trouble sooner or later.
> - If not, then LyX restricts the application of change
Lars Gullik Bjønnes wrote:
yes... tracker info is not stored directly in the row. so on a change
like this the row signature will stay the same.
LFUNS that require an update should perhaps make the row redraw
always.
Well, I don't know all the details of LyX but to me this does not sound
li
Michael Gerz <[EMAIL PROTECTED]> writes:
| John C. McCabe-Dansted wrote:
|
| >On Sunday 01 January 2006 01:15, Michael Gerz wrote:
| >
| >>SCREEN IS NOT UPDATED AFTER DELETION
| >>
| >> 1. New doc
| >> 2. Enter "hello"
| >> 3. Activate change tracking
| >> 4. Place cursor in front of "hello"
| >>
Lars Gullik Bjønnes wrote:
| UNCHANGED PARAGRAPHS CANNOT BE SPLIT
a bit more severe. This is basic functionality.
Yes.
| => The line break is visible again with a change bar to the left
| (OK!) but there is no way to accept this change because change
| tracking is deactivated. IMHO, ther
John C. McCabe-Dansted wrote:
On Sunday 01 January 2006 01:15, Michael Gerz wrote:
SCREEN IS NOT UPDATED AFTER DELETION
1. New doc
2. Enter "hello"
3. Activate change tracking
4. Place cursor in front of "hello"
5. Press delete key
=> The character is deleted internally but the screen is
I cannot replicate the following two bugs on lyx-1.4.0pre3-Qt, My system is as
follows: Kubuntu 5.10, gcc 4.02, QT 3.3.4, KDE 3.5. What version of LyX and
QT (or xforms or...) are you using? Are these MS-Windows only bugs?
On Sunday 01 January 2006 01:15, Michael Gerz wrote:
> SCREEN IS NOT UPDA
Michael Gerz <[EMAIL PROTECTED]> writes:
| UNDO OF LINE BREAKS FAILS
minor can wait.
| UNCHANGED PARAGRAPHS CANNOT BE SPLIT
a bit more severe. This is basic functionality.
| CHANGES CANNOT BE ACCEPTED UNLESS CHANGE TRACKING IS ACTIVATED
| 1. New doc
| 2. Enter "hello world"
| 3. Place curso
Hello,
I am sorry to say so but change tracking is not in a good shape at the
moment. There are many small problems that, in combination, make change
tracking almost unusuable. (If we were able to fix at least a few of
them, life would be much easier)
I have produced a set of test cases. I t
60 matches
Mail list logo
