Dov Feldstern <[EMAIL PROTECTED]> writes:
| Stefan Schimanski wrote:
| > Am 29.05.2007 um 09:35 schrieb Stefan Schimanski:
| >
| >>>
| >>> Can you give me a backtrace of it? Tried with RTL and LTR
| >>> paragraphs, everything works fine, no crash. Also tried Abdel's
| >>> example file from two wee
The two remaining known bugs are fixed. Abdel and Dov gave their ok.
Also gave the Mac binary to my brother to test it out extensively
with a text he is writing currently. If nobody comes up with
objections, I will commit in half an hour.
Stefan
Stefan Schimanski wrote:
Am 29.05.2007 um
Stefan Schimanski wrote:
Am 29.05.2007 um 21:02 schrieb Dov Feldstern:
Stefan Schimanski wrote:
Am 29.05.2007 um 18:59 schrieb Dov Feldstern:
Stefan Schimanski wrote:
I just tested again. With the latest version of the patch
(http://permalink.gmane.org/gmane.editors.lyx.devel/85600) I'm
ge
Am 29.05.2007 um 21:02 schrieb Dov Feldstern:
Stefan Schimanski wrote:
Am 29.05.2007 um 18:59 schrieb Dov Feldstern:
Stefan Schimanski wrote:
I just tested again. With the latest version of the patch
(http://permalink.gmane.org/gmane.editors.lyx.devel/85600) I'm
getting a crash. To reprod
Stefan Schimanski wrote:
Am 29.05.2007 um 18:59 schrieb Dov Feldstern:
Stefan Schimanski wrote:
I just tested again. With the latest version of the patch
(http://permalink.gmane.org/gmane.editors.lyx.devel/85600) I'm
getting a crash. To reproduce: (1) make sure RTL option is turned
on; (2)
Am 29.05.2007 um 18:59 schrieb Dov Feldstern:
Stefan Schimanski wrote:
I just tested again. With the latest version of the patch (http://
permalink.gmane.org/gmane.editors.lyx.devel/85600) I'm getting a
crash. To reproduce: (1) make sure RTL option is turned on; (2)
start typing (with spac
#4 0x0842dd8c in lyx::TextMetrics::computeRowMetrics
(this=0x8f33744, pit=0,
[EMAIL PROTECTED]) at Paragraph.h:286
Can you find out where exactly in computeRowMetrics the crash/assert
is triggered? Paragraph.h:286 is the getChar function. As far as I
can see, the getChar are all bou
Stefan Schimanski wrote:
Am 29.05.2007 um 09:35 schrieb Stefan Schimanski:
Can you give me a backtrace of it? Tried with RTL and LTR paragraphs,
everything works fine, no crash. Also tried Abdel's example file from
two weeks ago, no crash.
Stefan
The new patch, adapted to the whitespace
Stefan Schimanski wrote:
I just tested again. With the latest version of the patch
(http://permalink.gmane.org/gmane.editors.lyx.devel/85600) I'm getting
a crash. To reproduce: (1) make sure RTL option is turned on; (2)
start typing (with spaces, just normal typing) until the paragraph
breaks
Am 29.05.2007 um 09:35 schrieb Stefan Schimanski:
Can you give me a backtrace of it? Tried with RTL and LTR
paragraphs, everything works fine, no crash. Also tried Abdel's
example file from two weeks ago, no crash.
Stefan
The new patch, adapted to the whitespace changes.
And includin
Can you give me a backtrace of it? Tried with RTL and LTR
paragraphs, everything works fine, no crash. Also tried Abdel's
example file from two weeks ago, no crash.
Stefan
The new patch, adapted to the whitespace changes.
Stefan
cursordispatch.patch
Description: Binary data
PGP.sig
I just tested again. With the latest version of the patch (http://
permalink.gmane.org/gmane.editors.lyx.devel/85600) I'm getting a
crash. To reproduce: (1) make sure RTL option is turned on; (2)
start typing (with spaces, just normal typing) until the paragraph
breaks to a new line. Start m
Dov Feldstern wrote:
Abdelrazak Younes wrote:
Stefan Schimanski wrote:
I have fixed the logic now in my patch to equal that of LyX 1.4
exactly (see attached).
I've tested this last patch and all seems fine to me WRT cursor
movement. The code cleanup is good too.
Abdel.
Do you not get a
Abdelrazak Younes wrote:
Stefan Schimanski wrote:
I have fixed the logic now in my patch to equal that of LyX 1.4
exactly (see attached).
I've tested this last patch and all seems fine to me WRT cursor
movement. The code cleanup is good too.
Abdel.
Do you not get a crash with this versio
Stefan Schimanski wrote:
I have fixed the logic now in my patch to equal that of LyX 1.4 exactly
(see attached).
I've tested this last patch and all seems fine to me WRT cursor
movement. The code cleanup is good too.
Abdel.
Stefan Schimanski wrote:
>> It seems to me that the old way was more straightforward for
>> exactly the
>> same behavior. What are the advantages of the new approach?
>
> The advantages are that it is implemented and probably shorter
> without touching every cursor function. Otherwise there is no
Andre Poenitz wrote:
On Sat, May 26, 2007 at 10:23:01AM +0200, Stefan Schimanski wrote:
The logic is in fact not very complicated. The assumption is that you
only want a new target_x if you go up/down from inside a row.
So far the logic was that target_x is the target coordinate where we
want
On Sat, May 26, 2007 at 10:23:01AM +0200, Stefan Schimanski wrote:
> The logic is in fact not very complicated. The assumption is that you
> only want a new target_x if you go up/down from inside a row.
So far the logic was that target_x is the target coordinate where we
want to go to. It is set
The offset now just keeps track how far off we are after up/down (if
you do not hit the exact pixel column. To decide now if you really
want a new target_x as described above, you additionally check if
your current cursor position plus the offset is pixel-wise exactly
the old target_x. Then it's v
Stefan Schimanski wrote:
> The logic is in fact not very complicated. The assumption is that you
> only want a new target_x if you go up/down from inside a row. So if
> you are at the left or right of a row you only want to take a new
> target_x if it is further to the right than the old one (or i
Also take a look here: http://bugzilla.lyx.org/show_bug.cgi?id=2475
This bug has to do with the line break. The cursor at the newline
position should be shown in the previous line in front of the line
break symbol. The cursor one position after it should be shown in the
next line. But the cu
Dov Feldstern wrote:
Stefan Schimanski wrote:
I have fixed the logic now in my patch to equal that of LyX 1.4
exactly (see attached).
I think this is one step too far. There were bugs with the 1.4 logic
that were causing a crash, that's what I fixed a couple of weeks ago
(r18389). I thin
Stefan Schimanski wrote:
I have fixed the logic now in my patch to equal that of LyX 1.4 exactly
(see attached).
I think this is one step too far. There were bugs with the 1.4 logic
that were causing a crash, that's what I fixed a couple of weeks ago
(r18389). I think you copied the bug t
Am 28.05.2007 um 00:43 schrieb Dov Feldstern:
Dov Feldstern wrote:
In cursorLeft, for example: what is the condition "cur.lastpos() !
= cur.pos()" for?
And "cur.textRow().pos() == cur.pos()" (what does it even mean?)?
textRow().pos() returns the position of the first character in the
pa
Yes, I think your explanation of the concept is correct. Andre' gave a
few other examples, such as between italics and normal text. If you're
exactly on the boundary, should the next typed character be italic or
normal? And of course there's a similar situation between RTL and
LTR...
What I do
Dov Feldstern wrote:
In cursorLeft, for example: what is the condition "cur.lastpos() !=
cur.pos()" for?
And "cur.textRow().pos() == cur.pos()" (what does it even mean?)?
textRow().pos() returns the position of the first character in the
paragraph which belongs to the current row. So this
Stefan Schimanski wrote:
As far as I think to understand, boundary is set on line limits. If you
have a line like
"foo "
"bar"
the boundary flag is set if you are behind the space in the first line.
In the beginning of the first the boundary flag is false, but you use
the same position. That
As far as I think to understand, boundary is set on line limits. If
you have a line like
"foo "
"bar"
the boundary flag is set if you are behind the space in the first
line. In the beginning of the first the boundary flag is false, but
you use the same position. That's why it needed.
As
Stefan Schimanski wrote:
Fixed that and restored the old behaviour.
Stefan
I see we're playing this game again :) . I just sent in a slightly
different solution! As I keep saying though, I don't really understand
what's going on here... So if you *understand* your solution, it's
probably
Dov Feldstern wrote:
Stefan Schimanski wrote:
I think this version of the patch is ready to commit. I have tested it
on many examples and think the behavior is as it should be (up to some
minor points which can and should be addressed later). Below you find
some explanation of what the patch d
Hmmm... there are some minor changes in the behavior of LyX due to
your patches. For example, in a paragraph which spans multiple
lines: if you move back (left in LTR) from the first position in
the line, you used to be placed immediately after the last letter
on the previous line. Now, y
Stefan Schimanski wrote:
I think this version of the patch is ready to commit. I have tested it
on many examples and think the behavior is as it should be (up to some
minor points which can and should be addressed later). Below you find
some explanation of what the patch does and these issues.
Stefan Schimanski wrote:
I think this version of the patch is ready to commit. I have tested it
on many examples and think the behavior is as it should be (up to some
minor points which can and should be addressed later). Below you find
some explanation of what the patch does and these issues.
I think this version of the patch is ready to commit. I have tested
it on many examples and think the behavior is as it should be (up to
some minor points which can and should be addressed later). Below you
find some explanation of what the patch does and these issues. If you
haven't tried
Am 27.05.2007 um 02:24 schrieb Dov Feldstern:
My only comment regarding the code itself: I would suggest
separating the fix for bug 3720 from the rest of the patch here,
and applying them separately. They are not logically interdependent
(the fix for bug 3720 could be applied independently
On Sat, May 26, 2007 at 09:57:35PM -0400, Richard Heck wrote:
> Dov Feldstern wrote:
> >Stefan Schimanski wrote:
> >>In the last patch there was a bug with the script code in math.
> >>Fixed that. So here it is again. While looking through the
> >>FINISHED_UP/DOWN stuff I am starting to think tha
Dov Feldstern wrote:
Stefan Schimanski wrote:
In the last patch there was a bug with the script code in math. Fixed
that. So here it is again. While looking through the FINISHED_UP/DOWN
stuff I am starting to think that it has no effect whatsoever. I
don't create those LFUNs anymore, and still
Stefan Schimanski wrote:
In the last patch there was a bug with the script code in math. Fixed
that. So here it is again. While looking through the FINISHED_UP/DOWN
stuff I am starting to think that it has no effect whatsoever. I don't
create those LFUNs anymore, and still cursor handling seems
In the last patch there was a bug with the script code in math. Fixed
that. So here it is again. While looking through the FINISHED_UP/DOWN
stuff I am starting to think that it has no effect whatsoever. I
don't create those LFUNs anymore, and still cursor handling seems ok.
Stefan
cursor
Abdelrazak Younes wrote:
Stefan Schimanski wrote:
Attached is the patch and a test file for RTL.
With the attached test file for RTL, when keeping pressed the left arrow
key, starting from the top, the cursor will be stucked between the end
of the third (RTL) line and the beginning of the f
So here is a version using the dispatch system. The table works now
as well (though some behavior is questionable. But it's as well in
the Beta 3, so not matter of my patch).
As written in previous mail, I have no clue about the FINISHED_UP/
DOWNs. I don't "send" them anymore from anywhere, an
I had a very nice version of the patch, until I found out that tables
navigation is gone. The reason is that we have to use the LFUN_UP/
DOWN architecture with the dispatch mechanism to reach all the insets
which might want to implement custom cursor movement.
So I converted everything back
Martin Vermeer wrote:
> I'm impressed that somebody actually understands this stuff.
>
Me, too.
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
===
I'm impressed that somebody actually understands this stuff.
- Martin
Stefan Schimanski wrote:
Am 26.05.2007 um 11:20 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 26.05.2007 um 11:14 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
If we put this patch into RC1 we rather should put it in today than
tomorrow evening ten minutes before the release.
Am 26.05.2007 um 11:20 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 26.05.2007 um 11:14 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
If we put this patch into RC1 we rather should put it in today
than tomorrow evening ten minutes before the release. As far as
I can tell i
Stefan Schimanski wrote:
Am 26.05.2007 um 11:14 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
If we put this patch into RC1 we rather should put it in today than
tomorrow evening ten minutes before the release. As far as I can tell
it works fine and there are no immediate show stoppers
Am 26.05.2007 um 11:14 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
If we put this patch into RC1 we rather should put it in today
than tomorrow evening ten minutes before the release. As far as I
can tell it works fine and there are no immediate show stoppers in
the patch. But by
Stefan Schimanski wrote:
If we put this patch into RC1 we rather should put it in today than
tomorrow evening ten minutes before the release. As far as I can tell it
works fine and there are no immediate show stoppers in the patch. But by
committing it now others might test it at least a bit be
If we put this patch into RC1 we rather should put it in today than
tomorrow evening ten minutes before the release. As far as I can tell
it works fine and there are no immediate show stoppers in the patch.
But by committing it now others might test it at least a bit before
releasing it to
Am 26.05.2007 um 10:16 schrieb Alfredo Braunstein:
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Stefan Schimanski wrote:
So, the first P.S. is history now. I added an offset from the
x_target after moving to the next line. Using that the cursor knows
when it is actually meant to be o
Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
>> Stefan Schimanski wrote:
>>
>>> So, the first P.S. is history now. I added an offset from the
>>> x_target after moving to the next line. Using that the cursor knows
>>> when it is actually meant to be on the target, but had to move
>>> slig
Am 26.05.2007 um 09:51 schrieb Stefan Schimanski:
Am 26.05.2007 um 09:32 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Attached is the patch and a test file for RTL.
With the attached test file for RTL, when keeping pressed the left
arrow key, starting from the top, the cursor wi
Am 26.05.2007 um 09:32 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Attached is the patch and a test file for RTL.
With the attached test file for RTL, when keeping pressed the left
arrow key, starting from the top, the cursor will be stucked
between the end of the third (RTL) li
It's strange that an additional offset is needed. It is something
specific
for RTL? It used to work as following: target_x was never touched
on cursor
up and down, but adjusted on all other cursor movements.
When I cleaned up this, the target_x was touched everywhere :-). So
I decided to
Trying to find the in-mathed blocking reason now
This is caused (again) by a wrong boundary flag :-/ There must be
more place than cursorLeft/Right which do not care about boundaries.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Alfredo Braunstein wrote:
Stefan Schimanski wrote:
So, the first P.S. is history now. I added an offset from the
x_target after moving to the next line. Using that the cursor knows
when it is actually meant to be on the target, but had to move
slightly left or right to be between character.
H
Stefan Schimanski wrote:
Am 26.05.2007 um 09:22 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
P.S.: One minor known problem is that big insets (like labels) might
"move" the target_x value. This should be tackled later as well, but
not now.
Hum, this problem is not so minor as the the
Stefan Schimanski wrote:
> So, the first P.S. is history now. I added an offset from the
> x_target after moving to the next line. Using that the cursor knows
> when it is actually meant to be on the target, but had to move
> slightly left or right to be between character.
It's strange that an ad
Stefan Schimanski wrote:
Attached is the patch and a test file for RTL.
With the attached test file for RTL, when keeping pressed the left arrow
key, starting from the top, the cursor will be stucked between the end
of the third (RTL) line and the beginning of the fourth (LTR) line.
Abdel.
Am 26.05.2007 um 09:22 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
P.S.: One minor known problem is that big insets (like labels)
might "move" the target_x value. This should be tackled later as
well, but not now.
Hum, this problem is not so minor as the the up/down arrow key are
Stefan Schimanski wrote:
So, the first P.S. is history now. I added an offset from the x_target
after moving to the next line. Using that the cursor knows when it is
actually meant to be on the target, but had to move slightly left or
right to be between character.
Try it in the user manual.
So, the first P.S. is history now. I added an offset from the
x_target after moving to the next line. Using that the cursor knows
when it is actually meant to be on the target, but had to move
slightly left or right to be between character.
Try it in the user manual. You can scroll many pag
On Friday 25 May 2007 21:39:22 Abdelrazak Younes wrote:
> As far as I am concerned this patch should go in before RC1.
OK.
> Abdel.
--
José Abílio
Stefan Schimanski wrote:
Hi!
While looking through the cursor movement code to fix the problems with
the line skipping on Mac I started to clean it up a bit and most
importantly to get the target_x logic working again. So do that
(especially when moving out from the math insets into the text)
Hi!
While looking through the cursor movement code to fix the problems
with the line skipping on Mac I started to clean it up a bit and most
importantly to get the target_x logic working again. So do that
(especially when moving out from the math insets into the text) a
tighter integratio
66 matches
Mail list logo
