After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 788369 - Consider lowering the long-press delay before the subkeys menu is displayed
Consider lowering the long-press delay before the subkeys menu is displayed
Status: RESOLVED OBSOLETE
Product: caribou
Classification: Applications
Component: default
git master
Other Linux
: Normal normal
: ---
Assigned To: caribou-maint
caribou-maint
Depends on:
Blocks:
 
 
Reported: 2017-09-30 09:41 UTC by intrigeri
Modified: 2021-05-25 17:46 UTC
See Also:
GNOME target: ---
GNOME version: 3.25/3.26



Description intrigeri 2017-09-30 09:41:54 UTC
Context: Tails has just ditched Florence and now relies purely on GNOME's screen keyboard to support a number of usecases such as accessibility, protection against hardware keyloggers, and touch devices :)

Caribou (when used in GNOME Shell at least) displays a menu upon long-press, that allows entering e.g. accented chars. This is a common way accross OS'es to do it and it's great. But the time one has to hold the mouse click before that menu shows up might be too long: one Tails user, who's used to the same feature in Android, tried it but failed and thus believed that this feature simply did not exist in GNOME (and wondered how one can enter accented chars). This happened because on Android, the delay is much smaller (I'm told it's something around 250ms).

Is this purely a design decision, or are there technical reasons for the current length of the delay?
It seems we have a 1000ms hardcoded delay in GNOME. https://git.gnome.org/browse/caribou/tree/libcaribou/key-model.vala#n179.

If it's purely a design decision, I'll point the design team to this bug report. I gues that given Android's market share and the fact the screen keyboard is basic functionality on Android touch devices, Android is de facto setting the norm most people are used to in this area; thus, providing a vastly different UX in GNOME is bound to confuse users coming from Android (granted, I have no quantitative data to support my claim, only one single user report so far; if it helps I can probably run a cheap user testing session about it with 2-3 Android users and 2-3 people who don't use any touch device).
Comment 1 André Klapper 2021-05-25 17:46:00 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new enhancement request ticket at
  https://gitlab.gnome.org/GNOME/caribou/-/issues/

Thank you for your understanding and your help.