GNOME Bugzilla – Bug 53763
KEYNAV: GtkEntry
Last modified: 2011-02-04 16:09:32 UTC
By default, when a GtkEntry field has focus, Tab should insert a Tab character, and Ctrl+Tab (or Shift+Ctrl+Tab) should navigate focus away from that control. Since entering a Tab character in a single line entry field is often undesirable or not useful, though, it might be nice if GtkEntry controls supported a "don't allow Tab characters" flag (which ISTR is what MFC allows). Pressing Tab (or Shift+Tab) in a field that has that flag set would also then navigate focus away from that control, rather than inserting a Tab character. Ctrl+Right/Left arrow should move the text cursor to the beginning of the next/previous word. Shift+Ctrl+Right/Left arrow should extend the current selection to the beginning of the next/previous word. Home/End should move the text cursor to the beginning or end of the buffer Shift+Home/End should extend the current selection to the beginning or end of the buffer Pressing Enter should activate the window's default command button if it has one, otherwise do nothing. (Inserting a newline character is obviously not useful in a single-line text field). The user's currently-enforced cut, copy and paste keyboard accelerators should be supported in the input field. Emacs-style keybindings probably shouldn't be supported in entry fields by default, as they interfere with other things (like Alt+F to pull down the File menu)-- this should probably be handled by themable keybindings a desktop-global level.
Also, Ctrl+A should select all text in the buffer (should this also move the text cursor to the end of the text?), and Ctrl+\ should deselect all text in the buffer.
Oh yes, and Ctrl+/ should select all the text in the buffer as well (same as Ctrl+A).
Most support was shown for the idea of allowing the developer to choose whether tab characters should be allowed in individual text entry fields or not, by means of a flag or similar. If they're allowed, Tab key inserts a tab character, and [Shift+]Ctrl+Tab navigates out of the field. If they're not allowed, [Shift+]Tab and [Shift+]Ctrl+Tab both navigate out of the field. Default should be 'not allowed'. I will attach a patch to achieve this. I will also change the default value of activates_default, so that by default the Enter/Return key will activate the default button.
Created attachment 5743 [details] [review] Patch to correct Tab behavior
Great work! I found what I beleive is a minor typo in the patch though: _("Whether to allow the tab character to be inserted into the text of the widget when Tab is pressed."), There's a double space in the message that I don't think should be there. Again, thanks for doing this work.
Adding GNOME2 keyword to all keynav bugs per sander's request. You can filter on the phrase 'luis doing GNOME2 work' to catch all instances of this so that you can ignore them.
I just stripped out the emacs keybindings for GtkEntry and GtkTextView, which I believe makes the keybindings equal to that in the keynav spec. Remaining issues discussed in this bug are: 70985 - Add ::allow-tabs properties to GtkEntry, GtkTextView 70986 - Beep when moving off buffer in text widgets?