KEYNAV:GtkEntry And Accessibility (bug 53763)

["Padraig O'Briain" <Padraig Obriain Sun COM>]

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.

<POB> This is not implemented. Is this a nice to have or a mandatory? </POB>

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.

<POB> This is not implemented. Currently a Tab in a GtkEntry moves to the 
next field, How important is it that the default be to allow a Tab 
character rather than not allow a Tab chanracter? </POB>

Ctrl+Right/Left arrow should move the text cursor to the beginning of the
next/previous word.

<POB> Ctrl+Right arrow moves cursor to end of current word.
<Ctrl+Left arrow moves cursor to beginning of current word.
Is the behavior of Ctrl+Left arrow adequate? </POB>

Shift+Ctrl+Right/Left arrow should extend the current selection to the
beginning of the next/previous word.

<POB> The behavior extends the selection in the manner expected by the
implementation of <Ctrl+Right/Left arrow. </POB>

Home/End should move the text cursor to the beginning or end of the buffer

<POB> This works. </POB>

Shift+Home/End should extend the current selection to the beginning or end
of the buffer

<POB> This works. </POB>

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).

<POB> The behavior here depends on whether the function 
gtk_entry_activates_default() has been called. It seems that the default
behavior is for Enter to insert a newline character. It seems that what you 
are requesting is that the default behavior be changed. An application
can easily change the behavior of Enter. </POB>

The user's currently-enforced cut, copy and paste keyboard accelerators
should be supported in the input field.

<POB> I do not have a suitable test case to evaluate whether this works. </POB>

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.



------- Additional Comments From Calum Benson 2001-04-30 06:54 -------

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.



------- Additional Comments From Calum Benson 2001-04-30 08:40 -------

Oh yes, and Ctrl+/ should select all the text in the buffer as well
(same as Ctrl+A).