GNOME Bugzilla – Bug 741351
screen keyboard (caribou) always show regardless of the setting of universal access
Last modified: 2017-04-06 13:51:14 UTC
in Fedora and arch...
what version of g-s-d you have?
(In reply to comment #1) > what version of g-s-d you have? version 3.14.2 (from fedora 21)
caribou or gnome-shell's on-screen keyboard? Please attach a screenshot. Are you using a touchscreen?
Created attachment 292548 [details] screen
yes, I using a touchscreen (HP All-in-one PC)
The on-screen keyboard shows up when you use the touchscreen and there's a text entry? That's the way it's supposed to work.
yes, in GNOME apps.
*** Bug 758802 has been marked as a duplicate of this bug. ***
(In reply to Bastien Nocera from comment #6) > The on-screen keyboard shows up when you use the touchscreen and there's a > text entry? That's the way it's supposed to work. Hello Bastien, My generic bug about GNOME was marked as closed against this bug, as being a duplicate. So let me try see if we can see the problem here. GNOME is turning to be very monolithic. For components that the GNOME upstream has not chosen as defaults, using them is a PITA. Similarly, disabling features/services which are marked as default in GNOME, is problematic. And that is what this bug is about. Caribou may be good but is not optimal. And there are other choices too: like onboard, florence etc. An ideal framework would be to have it structured so that other, non-default, tools could also fill in incase the user wants to. Today, disabling Caribou, so that I can try onboard is too much work. There is NO single button (GNOME's KISS Philosophy) to disable caribou. Like you said, and such is the case, if you touch into a text input filed: org.gnome.Caribou.Daemon gets activated, and in turn triggers the Caribou keyboard.
> The on-screen keyboard shows up when you use the touchscreen and there's a > text entry? That's the way it's supposed to work. It might be the way it's supposed to work by the person who originally wrote the code, but I guarantee it is not the way a touch user expects a device to work, nor how other operating systems handle it. If a hardware keyboard is connected, the user will not expect a virtual one to show up (unless accessibility features are activated), even if the touchscreen is being employed. Currently, the presence or absence of a hardware keyboard has no effect on whether Caribou will show up in GNOME, and instead, as long as text input is available in the current focus, Caribou will appear whenever the touchscreen is tapped, and disappear as soon as a mouse or touchpad is used again, despite this being in no way directly related to the necessity of having a virtual keyboard available. I assume the original reasoning behind the current behavior was that if a touchscreen is in use, then the device is likely being used in a "tablet" mode that lacks a hardware keyboard, but this is only an indirect inference, and not at all valid on convertible ("laplet") devices for instance, while a much more direct test would be the presence of an active hardware keyboard.
The code in gnome-settings-daemon doesn't exist any more, all the on-screen keyboard handling is now done in gnome-shell.