GNOME Bugzilla – Bug 64132
GtkTextView problem with RTL layout and "wrap off"
Last modified: 2018-02-10 03:36:23 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
Confirmed that the bug still exists in pango-0.23/gtk-1.3.12 .
Confirmed that problem is still in pango-0.24/gtk+-1.3.13 .
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?
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
Move GtkTextView 2.0.4 bugs to 2.0.5
Moving bugs from older 2.0.x milestones to 2.0.10.
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.
I can't reproduce this bug. Does it still exist?
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.
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.