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 64132 - GtkTextView problem with RTL layout and "wrap off"
GtkTextView problem with RTL layout and "wrap off"
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
1.3.x
Other Linux
: Normal normal
: Medium fix
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: Persian Hebrew
 
 
Reported: 2001-11-09 09:01 UTC by Dov Grobgeld
Modified: 2018-02-10 03:36 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dov Grobgeld 2001-11-09 09:01:37 UTC
RTL layout and wrap off causes scrolling to always show the beginning of
the line instead of the end of the line.

To reproduce the problem do:

   1. Run testtext
   2. Choose Settings/Wrap off
   3. Choose Settings/RTL
   4. Enter enough neutral characters so that the line is wider
      than the widget widths. Example of such characters are
      !@#$%^&*().

When scrollbars appears the horizontal scrolling always
shows the beginning of the line instead of the expected
end of the line, where the cursor is positioned. 

Also Ctrl-E does not move the scrollbar.

Actually in order to solve this bug report we must make a decision about
how non-wrap should work with RTL text. In the two examples below
the minus sign shows hte widget width and xxx the text.

Option 1:

                      --------------------------------
1:             xx xxxxxx x xxxx xx xxxxxxx xxxxx xxxxxx
2:                xxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxxx
3:                     xxxxxx xxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxxxx

     Lines 1 and 2 are RTL and line 3 is LTR. The lines start
     at the right and the left margins respectively.

Option 2:
                      --------------------------------
1:                   xx xxxxxx x xxxx xx xxxxxxx xxxxx xxxxxx
2:                      xxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxxx
3:                xxxxxx xxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxxxx

    Lines 1 and 2 are RTL and line 3 is LTR. The lines start 
    at the end of the longest line in the opposite direction. In this  
    example the LTR line on line 3 is the longest and it determines
    the right margin and the start of the RTL lines.

I suggest that we code option 1.

Dov
Comment 1 Dov Grobgeld 2001-12-26 20:15:01 UTC
Confirmed that the bug still exists in pango-0.23/gtk-1.3.12 .
Comment 2 Dov Grobgeld 2002-02-09 21:59:46 UTC
Confirmed that problem is still in pango-0.24/gtk+-1.3.13 .
Comment 3 Havoc Pennington 2002-03-01 04:28:56 UTC
The bug here is in gtk_text_view_scroll_to_iter(), I _think_, but I
don't understand exactly what needs doing. Possible alternative 
is that text_view_iter_get_location() needs to flip the location
rectangle for RTL?
Comment 4 Matthias Clasen 2002-04-05 13:35:09 UTC
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
Comment 5 Owen Taylor 2002-06-14 15:31:14 UTC
Move GtkTextView 2.0.4 bugs to 2.0.5
Comment 6 Matthias Clasen 2002-11-21 19:00:49 UTC
Moving bugs from older 2.0.x milestones to 2.0.10.
Comment 7 Elijah Newren 2004-06-19 18:46:07 UTC
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as
Matthias said he was trying to do himself on IRC and was asking for help with. 
If you see this message, it means I was successful at fixing the borken-ness in
bugzilla :)  Sorry for the spam; just query on this message and delete all
emails you get with this message, since there will probably be a lot.
Comment 8 Djihed Afifi 2008-01-08 23:04:03 UTC
I can't reproduce this bug. Does it still exist?
Comment 9 Amit Aronovitch 2009-01-18 09:30:43 UTC
1. Seems like it does not exist as described, but one issue that is mentioned still remains: when you hit 'End' to jump to end of a RTL line, the scroll-bar remains at current position (cursor does jump to end and disappears from view). This needs to be confirmed, as I am not sure I fully understand the descriptions here.

2. Further details:

* From experimenting with tests/testtext, it seems that option (2) (lines start at end of longest opposite directionality line) in Dov's original bugrep was implemented.

* To reproduce, you must create a RTL line. The method described in the original bugrep does not work, because the widget direction (settings/RTL) does not effect the directionality of the lines themselves[1]. If you do not have a bidi keyboard layout, an alternative would be:
 right-click, "insert unicode control character", "RLM - right to left mark", then type enough neutral chars to make the scrollbar appear.

Footnotes:
[1] Directionality of a neutral line is currently determined by following priority list: (a) previous strong-directionality line (b) next strong-directionality line (c) (for current line only) directionality state of the keyboard.
Comment 10 Matthias Clasen 2018-02-10 03:36:23 UTC
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.