On a very high level, shouldn't the osk just be automatically turned on if there is no real keyboard ?

(In reply to comment #1)
> On a very high level, shouldn't the osk just be automatically turned on if
> there is no real keyboard ?

Yep. We can control that through gnome-settings-daemon (which already has policy for whether or not to show a cursor). Detecting keyboards will be a bit harder though, we need to ignore a whole range of "platform" keyboards (ACPI keys, laptop specific garbage, etc.), we also need to ignore infra-red remotes that don't have the necessary buttons, etc.

More work than detecting mice, but, again, this is for touchscreen devices. For a11y purposes, we probably need to find other heuristics.

(In reply to comment #2)
> (In reply to comment #1)
> > On a very high level, shouldn't the osk just be automatically turned on if
> > there is no real keyboard ?
> 
> Yep. We can control that through gnome-settings-daemon (which already has
> policy for whether or not to show a cursor). Detecting keyboards will be a bit
> harder though, we need to ignore a whole range of "platform" keyboards (ACPI
> keys, laptop specific garbage, etc.), we also need to ignore infra-red remotes
> that don't have the necessary buttons, etc.

Hm...

    - "real" keyboards have lots of keys, "fake" keyboards have few.
      (The Happy Hacking keyboard is probably a minimal "real" keyboard,
      and it has 60 keys. The "ThinkPad Extra Buttons" device on my
      laptop has 31 keys.)

    - "real" keyboards have certain specific keysyms on them that "fake"
      keyboards don't. (Like what? "1"? "A"? "Shift"? "Tab"?)


However, note that the ExoPC has a "AT Translated Set 2 keyboard" device even when there's no keyboard plugged in...


Also, in addition to the "no keyboard at all" case, there's also the "laptop is flipped into tablet mode and has no external keyboard" case. Pretty sure there's an ACPI switch indicating "tablet mode"?


> More work than detecting mice, but, again, this is for touchscreen devices.

Having an explicit "touchscreen present" indication would be useful too; we may want the osk to default to "attached to the bottom of the screen" if there is a touchscreen, but default to "floating" if not.

The Keyboard settings panel is for a physical keyboard I think and shouldn't really be present on tablets. I think this is more of Universal Access isn't it?

I'd have 2 options:
1) it's a tablet -> always show the OSK
2) provide toggle in universal access

The heuristics in 1) would live in gnome-settings-daemon (I'm thinking has_touchscreen && has_accelerometer == is_tablet). This would toggle 2 GSettings keys under org.gnome.desktop.a11y.applications:
- screen-keyboard-togglable boolean
  Whether the OSK can be turned off (in case 1) FALSE, in case 2) TRUE)
- screen-keyboard-enabled
  Whether the OSK is on (in case 1) TRUE, in case 2) show the switch in gnome-shell, or show it sensitive)

This is very similar to what the "a11y-settings" plugin does in gnome-settings-daemon.

Then, for the caribou GTK+ plugin to get loaded, we just need a .desktop file telling us that it depends on the org.gnome.desktop.a11y.applications/screen-keyboard-enabled GSettings key.

(In reply to comment #0)
> gnome-shell 3.2 will have an on-screen keyboard. We need preferences for that.
> 
> At a minimum, a checkbox for whether or not it's ever used. Not sure what else.
> 
> Yes, this bug is too vague at the moment.

FWIW, we already have a "Screen keyboard" switch under "Typing" in universal-access. We're missing the same in gnome-shell, and the code to handle tablets specifically.

And I will add that if we add a switch to gnome-shell, we'll also need to add it to gdm's a11y preferences.

(In reply to comment #7)
> And I will add that if we add a switch to gnome-shell, we'll also need to add
> it to gdm's a11y preferences.

With the login screen now using gnome-shell, that will be automatic.

I believe this is taken care off now.