feat(web): better touchscreen laptop support [KeymanWeb Does Not Support Touchscreen Laptops Well] about keyman HOT 6 OPEN

I think a possible answer to this would be to leave the existing code in place that decides which CSS to use, but then add a mousemove listener, and is a mousemove is detected, replace the LINK element that references the tablet CSS with one that references the desktop CSS instead. The force the page to reload.
See https://stackoverflow.com/questions/4817029/whats-the-best-way-to-detect-a-touch-screen-device-using-javascript/4819886#4819886 for a full discussion of different approaches and their pros and cons, as well as a code snippet (in one of the answers) that illustrates the mousemove listener. This would mean that on a touch-enabled desktop, the page would still initially load with the mobile look, but as soon as the user moves the mouse across any part of the page, it would switch to the desktop look. Probably not a perfect solution, but in practice, I think it would work pretty well. We'd want to test on both an Android tablet with a mouse as well as a small form-factor PC (I have a Windows 8 RT computer/tablet hybrid) to see if there is any downside when the full site gets scaled down to that size.

from keyman.

Just tried it on my Dell XPS 10 (running Windows 8 RT ) in IE. With or without the keyboard connected, the site displays poorly. The area above the text box is not collapsed to zero height (as it is on my full-size laptop), but nothing displays in it. The on-screen keyboard displays, covering roughly the bottom half of the display, but the globe button doesn't work, and attempting to type using the keyboard produces no visible results.

from keyman.

I think a possible answer to this would be to leave the existing code in place that decides which CSS to use, but then add a mousemove listener, and is a mousemove is detected, replace the LINK element that references the tablet CSS with one that references the desktop CSS instead.

@tombogle Unfortunately, it's not that simple. The touchscreen-oriented OSKs differ greatly from the desktop-oriented OSK, and at present they're explicitly designed for use on phones and tablets. I've investigated the code paths before, and it'd take a lot of work to enable the touchscreen-oriented OSK to work for touchscreen desktop devices. There is far, far more than just the CSS involved, as that area of the system is in considerable need of redesign and/or refactoring for clarity. There are a lot of random JavaScript code snippets throughout the system that trigger "touch vs not touch" code divergences.

from keyman.

Issue by mcdurdin
Wednesday Jun 3, 2015 at 12:37 GMT
Originally opened as KD-165

When running Chrome, IE or Spartan on Windows 10, on a Surface Pro, both keymanweb.com and Keyman Engine for Web are detecting the browser as a touch device, which means we get the touch centric model...

This is not good for running this combination on an external screen, for example.

from keyman.

We've had a rough workaround in place for a while now - touchscreen laptops are set to use the non-touch interface at this time. We have some prepared design work toward a full resolution, but more is needed and the task is low-priority at this time, as it is not part of our target for KMW 10.0.

from keyman.

It's been a long time coming, but as of #5665 we've finally gotten at least one fully-functioning model for using a fully-functional touch-based OSK layout on desktop devices. (with a mouse)

It's (now) actually pretty trivial to flip a couple of switches internally for the following bits:

• enabling either mouse-based and touch-based handlers on a single OSK.
  • a few extra tweaks would allow use of both on the same one.
• the new OSK type can easily swap among the active keyboard's defined layouts.
  • We'll need additional design work to enable this for standard use, but this gets us close to allowing user selection of the OSK layout.
  • So, it'd be possible to choose whichever form a user prefers.

More design work is needed to present these as options to a user and for properly presenting a touch-based OSK to users on a touchscreen laptop - our current touch-OSK model uses up a large proportion of screen space because it expects to be on smaller devices... and to compete with a mobile device's system keyboard. Those differences mean we should probably have something more tailored to touchscreen laptops.

from keyman.