ubuntu-phone team mailing list archive

[Robert Schroll <rschroll@xxxxxxxxx>]

On Tue, Mar 25, 2014 at 10:04 AM, Alexandre Abreu 
<alexandre.abreu@xxxxxxxxxxxxx> 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