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 finally. - 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 href="http://bugzilla.gnome.org/show_bug.cgi?id=116626">116626</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 situation... 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.
Hi Owen, ...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 loaded document. - 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 broken. 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 use.
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 the effort.
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