GNOME Bugzilla – Bug 50770
Input widgets should have keyboard accels. to switch strong LTR/RTL
Last modified: 2018-04-15 00:24:59 UTC
The necessity of the feature: In daily work with BiDirectional input, the ability to quickly switch a text input widget from an "English text with occasional Hebrew inside" to a "Hebrew text with occasional English inside" mode is crucial (replace Hebrew with your favorite RTL language). This is from my long experience of using Hebrew-enabled version of Windows 95. Why on the widget level, and not per-application?: This feature should be on the widget level, since we don't expect every application developer to add "support for BiDi" in their application. Implementing this on the widget level would make this feature available transparently in all applications, and would make sure they key combos used to switch modes are unified. Example: In a chat or an IM application (those which weren't specially designed for BiDi in any way), you'd want to be able to communicate in English with one person, while communicating in Hebrew sentences with the other. You cannot write full Hebrew sentences in an LTR-aligned widgets, since the punctuation will be appended to the right and occasional LTR text will cut the RTL flow, thus making the text appear misformatted on the screen. It's difficult to type and re-read. It'll also be difficult to read Hebrew text the other person sends, if they wrote it as RTL text, while we see it in an LTR input widget (unless their client embeds Unicode formatting characters). Microsoft Windows: Microsoft Windows allows you to switch a text widget to strong-LTR via a LeftCtrl+Shift key combo (while inside the text widget), and to strong-RTL via a RightCtrl+Shift key combo. Switching to RTL would also cause Windows to switch the keyboard layout to the first available RTL language (e.g. Hebrew), while switching to LTR would cause Windows to switch to the keyboard layout to the first available LTR language (e.g. English). While not required, this is a very handy feature, and the Israeli Hebrew-enabled Windows users are probably very used to it. Microsoft Windows's approach proved there are GOOD reasons to do it on the widget level (no change on application level), and no good reason to expect this from application developers.
The <ctrl><shift> combo isn't available, because that is used (by ISO standard) for Unicode entry. This is pretty easy to implement, though changing the widget directionality (gtk_widget_set_direction()) seems a little broken to me - this is something that the application would normally. The particular edit control that you changed the directionality in would remember the directionality "forever" even after you had switched out somewhere else. Is this feature needed both in GtkEntry and GtkTextView?
Yes, it is essential for both single-line and multi-line input boxes. Please believe me this should be on the toolkit level. I do not expect GnomeICU, GAIM or xchat to have *even one line* in their source code devoted specially for BiDi -- they simply won't do it. And especially I'd hate having each of those applications assign their own keyboard shortcuts to this global operation, without an ability to change it somehow in a centralized fashion.
Created attachment 6911 [details] [review] Prototype patch for adding such a binding to GtkEntry
The attached patch, in combination with a .gtkrc-2.0 entry like: binding "entry-rtl-switch" { bind "<control>r" { "switch-direction" (rtl) } bind "<control>l" { "switch-direction" (ltr) } } class "GtkEntry" binding "entry-rtl-switch" Provides a proof of concept of a simple example implementation of key bindings for switching directions in GtkEntry. Without some experience with it in practice, I don't want to rush it into GTK+-2.0.0. (And integration with the keymap would take more work.)
Moving non-critical and hard-to-fix bugs to 2.0.2
Is <ctrl><shift> a modifier combination for entering Unicode characters (i.e. it must be accompanied with a Unicode entity number)? If so, it is no problem to assign <ctrl><shift> for the task of switching directionality -- you can simply wait until the key combo is de-pressed to see whether <ctrl><shift> were pressed alone, or were eventually accompanied by an entity number. Is it possible via the .gtkrc configuration scheme you offer? Another good reason to go for <ctrl><shift> scheme is that Qt 3 uses it too now.
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
If using <ctrl><shift> for toggling is important for interoperability, this should probably depend on bug 82011.
2.4.0 will have automatic paragraph/base direction from paragraph contents which should mostly eliminate the need for this, so I want to wait until after we have some feedback on that before making changes here.
I believe this binding is still needed. The automatic direction simply can't get all cases right. Besides, that'll make Gtk work more similar, not only to Win32, but also to Qt, which has both automatic behavior and an ability to force direction (with Ctrl-Shift).
(In reply to comment #9) > 2.4.0 will have automatic paragraph/base direction from paragraph > contents which should mostly eliminate the need for this, The automatic paragraph/base direction is good for many cases, but many cases it gets wrong (classic example- Hebrew paragraph starting with a Latin word, or when editing mixed Hebrew/html-xml markup text). So a keyboard shortcut to control the directionality is still needed IMHO.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new