And the UI support on iOS for kbds relies on the UITextInput protocol which is very limited (and I now understand why Apple did it that way and hid the internal GSEvents for Kbd input) .

That's what the iStackVM does and what I removed for intercepting the low level events.

http://developer.apple.com/library/ios/#Documentation/UIKit/Reference/UITextInput_Protocol/Reference/Reference.html

But that makes sense since you need to support a lot of stuff for i18n.

And let's not get started with dictation and accessibility: two things at which Pharo is hopeless in Morphic.

Let's face it, for most apps, the UI is now the browser and that's about it.
The other space would be OpenGL based apps and there accessibility makes no real sense.

Phil




On Tue, Jun 11, 2013 at 9:47 AM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
You mean doing web app?
In that case, is not Amber a better choice ?


Hilaire


2013/6/10 phil@highoctane.be <phil@highoctane.be>

hence the bt kbd. the on screen kbf is useless.

as John McIntosh told me: do an app in the webview with seaside.

he was damn right.

phil

Le 10 juin 2013 21:23, "Hilaire Fernandes" <hilaire.fernandes@gmail.com> a �crit�:

More than the keyboard, you need to consider how the text field widget
behave when the keyboard show up. Indeed your virtual keyboard may just
overlap with your text field. Then how do you move the text cursor? What
about sliding it with the finger, with an additionnal widget showing it
zoomed because your large finger hide a large part of your text.

Hilaire


Le 10/06/2013 19:11, Torsten Bergmann a �crit :
> Tablets are more and more used and I wonder
> if there is a virtual keyboard [1] for Pharo available.
>
> Thx
> T.
>
> [1] http://2.bp.blogspot.com/-_p_I7WgFsZQ/UAiI1qjZYuI/AAAAAAAAED8/zyY0wdx_XJI/s1600/3.PNG
>


--
Dr. Geo - http://drgeo.eu





--
Dr. Geo - http://www.drgeo.eu