GNOME Bugzilla – Bug 136529
Auto direction code should not respect keyboard layout anymore
Last modified: 2014-03-27 02:59:31 UTC
Using the latest glib/pango/gtk+, all from CVS, which means bug <a
href="http://bugzilla.gnome.org/show_bug.cgi?id=70451">70451</a> is fixed.
The new observations:
* When I start gedit under fa_IR.UTF-8 locale, the menus jump to right,
which was the case before, but the cursor is on the left of the TextView.
It used to be on the right before this patch.
* - Make sure you don't have any Hebrew or Arabic keyboard layout loaded.
- Start "LANG=en_US.UTF-8 gedit".
- Launch gucharmap and select and copy an Arabic (or Hebrew) letter.
- Paste the Arabic letter in gedit. The cursor and the letter would
jump to the right of the TextView.
- Now press enter to go to the next line, which is also a new
paragraph. Cursor jumps to left, while should remain at right.
- Now enter a bidi-neutral character, like a single period ("."). It
remains on the left of the screen, while the paragraph auto-direction
algorithm says that it should inherit the direction from the previous
paragraph and set right-aligned.
- Press enter. You would go to the next line, and the line with the
period in it would jump to the right of the screen, following the algorithm
- Now if you press the "Up Arrow" to come to the line with the period
in it again, the line jumps to left again...
Dov Grobgeld said that he cannot reproduce it with a Hebrew keymap loaded.
It seems to be related to the code that is referred to in bug <a
Even in that case, I guess that if you start under he_IL.UTF-8 locale and
instead of Arabic or Hebrew text, enter English text you get jumping lines.
In my opinion as a bidi expert and native user, this behavior should be
fixed such that:
* paragraph direction never depends on the keyboard map.
* paragraph direction never depends on the presence of the cursor
* the fix should **NOT** be to add Persian to the list of recognized
keyboard layouts, or some other magic.
So the solution is to simply remove the old heuristic and rely on the
robust new algorithm all the time.
I propose to set this bug a blocker for the GNOME 2.6 final release. So
proper tagging is appreciated.
Can you try the behavior with, say, an Arabic layout (or
make up a patch for bug 116626, that is needed anyways for
correct operation of GTK+ with a Persian keyboard...)
I think that will be more useful than just imagining the
Though I'm *not* a native speaker of a bidi (or a speaker at all,
for that matter), the behavior with the neutral direction
following the keyboard seemed much more natural to me,
especially for empty paragraphs and/or at the beginning
of the document.
...but you are the master!
I tested it with an Arabic keymap and it behaved as I guessed. So,
here is the bad behavior: You have an English document in gedit, with
some paragraphs of pure netural characters (">" in an email). You
have selected Arabic keymap, and you are translating this text in
another window. Then you switch to the mentioned gedit window and
start navigating up and down the English document. Surprisingly you
see that whenever you put the cursor in a line that is completely
bidi-neutral, the line jumps from the left side of the window to the
right side, and it goes back to left as soon as you leave the line.
I think this kind of fallback to the direction of the keymap is a good
thing, but only if you add enough meta information that keeps the
direction. In this case it would mean to save the direction somewhere.
But even if you save this extra information, here comes evil problems:
* You copy/paste the text, and get it aligned on the other side of
the screen. Or even if you save/restore the document... To solve
this, you can put a hidden LRM or RLM in the beginning of the line if
the line is completely neutral.
* Then more evil keeps coming:
- Should you remove the LRM and put and RLM if user changes keymap
on the line? What if he types a bidi-strong character? Now what if
he has put the LRM or RLM mark himself? We cannot detect it on a
- It looks really bad, like what is it in MS Excel these days:
You have the same number 1234 in two fields, but one is aligned to
left, one to right. You should copy/paste one on the other one to
make them aligned on the same side...
You see, it's really complicated. One thing that needs no discussion
is that the current behavior that we decide based on keymap, but
*forget* our decision when the cursor leaves the line, is definitely
In the long run, we should develop some *intelligence* in there, but
that's not been implemented in any system yet, and needs a bit of
thought and testing before it goes out. So it belongs to GNOME2.7
time. The easiest fix now is to disable the keymap code.
Sorry, it turned out to become long and unclear. Please let me know
if you need a better-written explanation.
I think we should definitely avoid magically inserting marks
to remember what direction a line was when created.
The problem with not paying attention to the keymap direction
is that it's quite disorienting when entering a character
causes the line to jump. If you are, say, filling a bunch
of entries with text opposite to the UI direction, you'll
jump for each one.
Perhaps we should only pay attention to the keymap direction
for entries / text views that are *entirely* neutral? (Basically,
to get the empty entry case right?)
I'm going to put this on 2.4.1, because I don't think it's
realistic to try to make a change here before monday. I'd
also like any change we put in to be tested some in live
I still have inherent problems with any system that by leaving the
field it will change the direction, but your proposal of falling back
on kemap if the whole buffer is neutral seems far better than the
current situation. Perhaps Dov can prepare a patch?
And if you want my personal desire, if it's the case that you are
entering Persian in every field, so you should have started it in
Persian locale. Otherwise the jumping behavior is not that much
annoying. [maybe I'm not a nomal *user* though]
BTW, can you please have a look at the kemap patch? And thanks for
I just checked the sources and it is a trivial change to get the
behaviour that the keyboard direction is the last resort only if the
whole buffer is neutral. All that is needed is the following change:
--- gtktextlayout.c 11 Mar 2004 15:42:49 -0000 1.99
+++ gtktextlayout.c 15 Mar 2004 06:06:56 -0000
@@ -1836,7 +1836,7 @@ gtk_text_layout_get_line_display (GtkTex
base_dir = line->dir_propagated_back;
if (line == priv->cursor_line &&
- line->dir_strong == PANGO_DIRECTION_NEUTRAL)
+ base_dir == PANGO_DIRECTION_NEUTRAL)
base_dir = (layout->keyboard_direction == GTK_TEXT_DIR_LTR) ?
PANGO_DIRECTION_LTR : PANGO_DIRECTION_RTL;
(base_dir at this point holds the forward or the backward propagated
direction. If both of these are neutral at this point, then the whole
buffer is neutral.)
Now we only have to decide if this is really the behaviour that we want...
Thanks Dov. I think this is at least a better behavior with no
obvious flaws. I just tested your patch and it works great IMO.
We'd like to have some more feedback from RTL speakers if this patch is really
the desired behaviour. Dov ?
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.
Dov, thinking again, I think that if there's no strong character at all, we need
to change the whole buffer direction to the keyboard direction, not only the
current line. Is it hard to do this?
Nothing is difficult as long as we reach a conclusion of what we want. I'll try
to raise the issue on the Hebrew linux site and will see what they think.
Sure. Please CC us at the bidi list
(http://freedesktop.org/Standards/bidi-spec), or better, bring people there and
raise the discussion there. That's the whole goal of the project after all.
closing out ancient bugs