Bug#262004: rhythmbox: text entry fields don't honor gnome keybindings, at least emacs ones

[Loïc Minier]

Nick Mitchell <firepile@speakeasy.net> - Wed, Oct 13, 2004:

> for example, in gnome-control-center, the openbox window preferences, 
> there's a text entry widget, and all the normal emacs keys function as 
> expected (meaning: every emacs control-key cursor navigation command 
> works as expected)

 Sorry I could not reproduce that, I can launch control-center, then
 launch window preferences, but I see not text entry widget in there!
 Screenshot: <http://joule.via.ecp.fr/~lool/window-preferences.png>

> but in rhythmbox and sound-juicer, only some of them work; control-b, 
> which should be a backspace --- well, instead of the control-b being 
> intercepted by the text entry (it, after all, has the focus), is instea=
d 
> passed through as an application-global keypress, and interpreted as 
> things like "show/hide browser";   in sound-juicer, control-a, which 
> should be "go to beginning of line", is instead interpreted as an 
> appplication-global "select all tracks"

 Rhythmbox has too many keybindings requirements, and they end up
 filling the keybinding space.  But I really can't understand your
 request, it seems you want something you have seen working in other
 GTK/GNOME apps, where I didn't.

 For example, in a shell, you can type ^A ^E ^U and ^W to go to beginning
 of line, end of line, delete a line and a word.  This is not possible
 in GTK text entry widgets, as proves the Run dialog.  They simply
 behave differently.  This like asking for abiword or gedit to have a
 vim-like input mode.  While this is technically feasible, such a
 feature necessarily compete with keybindings provided in the
 applications emulated.  For example, almost all keys are bound in vim,
 emulating vim input mode would mean that no keybinding would remain for
 rhythmbox.

> i have no problem with control-a being "seelct all tracks" when the 
> focus isn't in a text widget;

 I heard they are rewriting the keybinding part in current rhythmbox to
 be more global than it is right now, so things are going to be worse I
 fear.

> similar bug: i'm typing this in thunderbird; i hit control-a and 
> control-e: while in the text entry widget, they work as emacs keys (eve=
n 
> though they have different meanings in an application-global focus); 
> however, control-p and control-b, and control-f always fire the global 
> handlers (respectively "print", "toggle boldface", and "find")

 So you've got the problem with thunderbird, and I can tell you that ^A,
 ^E and others simply don't work in the Galeon URL input field, and they
 probably never will.  I think you're expecting something that has been
 included by design in GTK.

> at the very least, these applcations should be consistent, one way or 
> the other: do we owner *all* or *none* of the emacs keybindings; as it 
> is, depending on the application, it's a random assortment!!

 I think the designers of the applications you mention never tried to
 have something similar to emacs, but either something effected by the
 random user.  Maybe they inspired from Windows, I tend to see similar
 behavior in widgets.


 To summarize a bit, I think you would like a new mode of input for all
 text entry fields in all gtk applications that would behave as emacs
 does for text input and override the application keybindings
 temporarily.  Did I understand your wish correctly?

   Regards,

-- 
Loïc Minier <lool@dooz.org>