GTK+ Touchscreen Mode

Touchscreen Mode (previously called stylus mode here) is when the primary pointing device is a stylus, and not a mouse. This causes problems with various widgets which needs to be patched in handheld devices, if there was an XSetting to modify the widgets behaviour then using GTK+ on handhelds would be easier.

Changes

  • No tooltips (in HEAD)
  • No right mouse button for context menus etc, implying an implementation of tap-and-hold

  • Multi-row selection in GtkTreeView by dragging (in HEAD)

Tap'n'Hold

There are at least two implementations of "tap'n'hold", where holding down the primary button for a short time is interpretted as a secondary button click (as on OS X).

Maemo has a patch which adds a callback to to GtkWidget and allows an animation to play when the hold is in process, and arbitary callbacks on "click".

libgtkstylus, from the GPE project, is a GTK+ module which registers an event filter. This has less features (no animation support, and it always sends a right click) but is standalone and a far smaller code base.

I'm leaning towards the libgtkstylus approach: it's less intrusive on GTK+, can be distributed on it's own, and I believe that all use-cases for tap'n'click can be implemented by handling a right-button click. The only missing feature is the animation, is this worth dropping?

  • Without the animation there will be no feedback or any hint that holding down the stylus longer would be doing something else --TommiKomulainen

Notes

From tko: from the top of my head you need to handle (multiple selection) treeview differently, and dnd starts getting in the way there .menus had some issues also, I think.

Gtk+ PhoneKeypad Mode

--YuYijun

When Gtk+ used in phone devices, it maybe need Phone Keypad mode. Usually phone keypad only has limited key buttons and among them, only four arrow keys(Up/Down/Left/Right, and no Tab key) can be used for focus navigation. Therefore, we want to made the following modifications to Gtk+:

  1. KEY_UP/KEY_DOWN will move focus up or down(GTK_DIR_UP/GTK_DIR_DOWN) as stock Gtk+ does
  2. KEY_LEFT/KEY_RIGHT will move focus forward or backward (GTK_DIR_TAB_FORWARD/GTK_DIR_TAB_BACKWARD) as Tab key or Shift+Tab key does. If the text direction is GTK_TEXT_DIR_RTL, then KEY_LEFT will move focus as GTK_DIR_TAB_FORWARD and KEY_RIGHT will move focus as GTK_DIR_TAB_BACKWARD; if the text direction is NOT GTK_TEXT_DIR_RTL, then KEY_LEFT will move focus as GTK_DIR_TAB_BACKWARD and KEY_RIGHT will move focus as GTK_DIR_TAB_FORWARD
  3. Some widgets could trap arrow keys and do not allow focus moved out of the widgets by pressing these arrow keys. Therefore:

    3.1 For GtkEntry,

    • KEY_UP/KEY_DOWN will move focus up or down as stock Gtk+ does; KEY_LEFT/KEY_RIGHT will move focus forward or backward when the cursor now is already in the leftmost position or rightmost position;

    3.2 For GtkSpinButton and GtkComboBox,

    • KEY_UP/KEY_DOWN behaviors are unchaged; KEY_LEFT/KEY_RIGHT will move focus forward or backward;

    3.3 For GtkTextView

    • KEY_UP/KEY_DOWN/KEY_LEFT/KEY_RIGHT will move focus out of the widget if the cursor now is already in the first line/last line/top left cornor/right bottom corner.
    3.4 for GtkHScale
    • KEY_UP/KEY_DOWN will move focus forward or backward; behaviors of KEY_LEFT/KEY_RIGHT are not changed;
    3.5 for GtkVScale
    • KEY_LEFT/KEY_RIGHT will move focus forward or backward; behaviors of KEY_UP/KEY_DOWN are not changed;

    3.6 for GtkRadioButton

    • Arrow keys will move focus forward or backward, but do not automotically activate the current focused radio button. The radio button could be activated only by you press Ok key in phone keypad(similar to Space key in normal keyboard);

    3.7 For GtkScrolledWindow

    • When focus is moved among children of the parent GtkScrolledWindow, the slider should move accordingly to show the current focused child. It seems that there is no need to modify GtkScrolledWindow when using it in phone devices, however, something should be kept in mind: 1) usually we do not need horizontal scrollbar in phone devices; 2) we should call function gtk_container_set_focus_vadjustment()

    • to scroll the adjustment to show the current focused widget automatically.

    3.8 For GtkIconView

    • 1)When focus moves to the leftmost GtkIconViewItem and KEY_LEFT pressed again, focus will move to the rightmost item of the line above; 2)When focus moves to the rightmost GtkIconViewItem and KEY_RIGHT pressed again, focus will move to the leftmost item of the line below; 3)When focus moves to the top-left corner(the first item) and KEY_LEFT pressed again, focus will move to the bottom-right corner(the last item); 4)When focus moves to the bottom-right corner(the last item) and KEY_RIGHT pressed again, focus will move to the top-left corner(the first item);

    3.9 For GtkTreeView

    • When focus is reached to the rightmost or leftmost of the current row, a signal row_right_end_reached is emitted with an argument indicating which side is reached. This signal is useful in the following situation: when the parent widget is a GtkNotebook

and focus is moved to the rightmost of leftmost side of the current row, then focus will be moved to the next or preivous page of GtkNotebook.

Tommi says that when there is no tab key, keyboard navigation needed work.

Some handheld devices have no pointing devices at all just key based input. Supporting this combined with above ( tabbing is rarely used in this kind of situation more the dpad ) means an alternate key navigation 'mode' ?

Maemo also has patches to enable "insensitive-press", where buttons can receive signals although they are disabled. This is used to explain why the button is disabled.

Existing Bugs

  • gnomebug:135666: Add style property to disable prelight
  • gnomebug:315112: Add XSetting to disable tooltips (in HEAD)
  • gnomebug:315645: Support hold-as-right-click
  • gnomebug:318827: Enable gtk+ to support keyboard navigation using phone keypad

Attic/GtkStylusMode (last edited 2013-11-22 15:43:35 by WilliamJonMcCann)