On Tue, Mar 25, 2014 at 10:04 AM, Alexandre Abreu
<alexandre.ab...@canonical.com> wrote:
Hi Robert,
The gist of the issue is OSK not popping up when js sets the focus in
a text field.
I'll agree that fixing this would be enough for me to get by with.
But...
I dont think that having a way to programatically popup the OSK w/o a
given "target" (text input field, etc.) is sound as a use case for a
given API. It opens the gate for quite a few edge cases and adds
quite a bit of complexity to have a reliable interface. It does not
even work in QML afaik (you need a text field and can only hide() the
inputMethod).
I admit I haven't though about this much, but I'm not sure I see the
problem. Both HTML and QML have well established rules for how
keyboard focus behaves when the focus isn't in a text entry, so that's
not a problem. I guess there's a worry about when a keyboard should
hide after an app requests it be opened. But a "you break it, you
bought it" philosophy seems appropriate: once an app explicitly shows
or hides they keyboard, the automatic bit turns off and the app is
responsible for handling the keyboard state in the future.
This isn't such an esoteric feature. Off the top of my head, I'm aware
of another app (Word Chain) that needs alphabetic input without a text
entry. It solves the problem by implementing its own OSK. The
alternative to having the SDK provide this is to have every app
implement it's own solution, hack, or work-around. This means that
each will behave slightly differently, which can't be desired.
Robert
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
