After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 149785 - Caret reading by word in Evolution fails to read the first word of a new line when crossing a line boundry
Caret reading by word in Evolution fails to read the first word of a new line...
Status: RESOLVED FIXED
Product: gnopernicus
Classification: Deprecated
Component: speech
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Dana Ormenisan
Dana Ormenisan
AP2
Depends on:
Blocks:
 
 
Reported: 2004-08-10 05:08 UTC by korn
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.7/2.8


Attachments
proposed patch (2.98 KB, patch)
2004-08-23 10:59 UTC, Dana Ormenisan
none Details | Review

Description korn 2004-08-10 05:08:32 UTC
1. Launch Evolution 1.4.6
2. Open the Default e-mail message (or some other with blank lines, images, etc.)
3. Run Gnopernicus
4. Make sure Caret navigation is on (F7), and that you have a text caret
5. From the top of the e-mail message, press down arrow repeatedly.
6. When you get to a line with lots of text (e.g. the first line of the default
message, starting with "Welcome to Ximian Evolution...", use Ctrl-right-arrow to
read by word.
7. Keep going past the last word of the line and onto the next word of the
second line.  Instead of reading the first word of that new line as it should
("workgroup" in my case), it reads the entire line, as if the user had pressed
down-arrow instead of ctrl-right-arrow.

Note: this may be related to Evolution bug #62763 - see:
http://bugzilla.ximian.com/show_bug.cgi?id=62763 and also to Gnopernicus bug #149784
Comment 1 Alexandra Telescu 2004-08-12 10:03:27 UTC
I am not sure if this is really a bug ... 

In Gedit, I observe the same behavior.
Reading word by word, the first word of a new line is not reported, but the
whole new line is reported instead.

If the difference between  new_offset and old_offset is bigger that 1,
gnopernicus does not know if it is a an 'up/down' navigation or a 'word by word'
navigation, because the events comming from keys and objects are not time
ordered. In such cases, if the old_offset and new_offset are in different lines,
the new line is reported else the word is reported.


Comment 2 korn 2004-08-12 18:01:29 UTC
Alexandra - are you saying that this bug, 149785 is not a bug, or evolution bug
#62763 is not a bug, or...?  Gedit behaves as Evolution does (behavior described
in evolution bug #62763), and I believe a bug is already filed against Gedit for
that.

I understand Gnopernicus' logic, and that logic is flawed as you note:
Gnopernicus is not distinguishing between a by-word that crosses a line boundry
and a by-line move.  I think Bill has some ideas as to how to do this without
sniffing the keystrokes (as should now be do-able with XEvIE).  Perhaps he might
comment?
Comment 3 Alexandra Telescu 2004-08-13 06:56:35 UTC
I was talking about this bug(# bug 149785), saying that,_in this moment_, from
gnopernicus point of view this is not a bug, but a current behavior (gnopernicus
has this behavior on all the applications, for every multiline text).
Comment 4 bill.haneman 2004-08-13 12:26:26 UTC
I agree with Alexandra that when moving from one line to another there's no way
for gnopernicus to know whether the movement was due to a "next word" or "next
line" command; in some cases the text-caret move events will be
indistinguishable for the two cases.

It may be possible to improve this behavior by extending the gnopernicus logic
thus:  when gnopernicus is notified that the caret has moved to a new line,
gnopernicus can check to see if the caret has moved by only one word or not.  In
other words, gnopernicus can check the previous & new offsets against the
results of a getTextAtOffset(text, WORD,...) call, and in this way, distinguish
between "line" navigation and "word" navigation.

Note that checking "column" offsets in the previous/new line _won't_ work,
because it will fail at the ends of lines of uneven length, and also will fail
for proportional fonts.  So in order to tell line-by-line movements from
word-by-word movements, any gnopernicus logic would have to call
getText{At,Before,After?]Offset and compare the word boundaries to the caret
movement it just received.
Comment 5 Dana Ormenisan 2004-08-23 10:59:42 UTC
Created attachment 30849 [details] [review]
proposed patch

Proposed patch to report only the word (and not the entire line) when user
navigates word-by-word and caret moves to a new line inside the same paragraph.
Comment 6 Dana Ormenisan 2004-08-23 11:05:00 UTC
This patch fixes also bug #149784.
Please test it and let me know if I should apply it and close the two bugs.
Comment 7 Alexandra Telescu 2004-08-26 07:54:55 UTC
It works for me. 
I tested the patch in evolution and gedit.
Comment 8 Dana Ormenisan 2004-08-27 07:57:47 UTC
Patch applied in CVS.