On 30 Jun 2010, at 00:18, "C. Scott Ananian" <[email protected]> wrote:
> On Tue, Jun 22, 2010 at 4:28 PM, Sayamindu Dasgupta <[email protected]> > wrote: >>> - Ideally something (Gnome I assume?) should trigger the keyboard overlay >>> when you focus on a text field, perhaps with some hints about what the >>> 'return' key behaviour should do (or expose a tab key as that is usually >>> the other common text field navigation method). Dismissing the keyboard >>> overlay when a text field is defocused would also be ideal. >> >> AFAIK, this requires a GTK+ module to be loaded. I'm still trying to >> write a proof of concept implementation of this - it seems that >> there's no documentation anywhere for writing GTK+ modules :-( > > Yeah, I gave up and just used LD_PRELOAD when I had this problem. If > you want to try the quick-and-dirty way for a proof of concept, this > might be handy: > http://dev.laptop.org/git/users/cscott/journal2/tree/ > > Do all of firefox/xulrunner/chrome use GTK widgets for text entry? > I'm nervous that some programs might not pop up the keyboard > appropriately. > > You could add a gesture to force the keyboard up even for badly > behaved applications. I think the iPad/iPhone gesture for that is > dragging your finger from the bottom of the screen to the top. FWIW: There is no global system gesture or button on the iPad for revealing the virtual keyboard. Selecting any text widget will reveal it; app developers can programatically reveal it (say if they have a custom canvas, our Labyrinth activity would fall in this category); a few individual apps from 3rd parties (none I can see from Apple) have added their own floating semi transparent keyboard icon usually in the far lower right screen corner, in one case (a text chat app) this just seems like poor design, in the others I can remember it's for cases where there is no sane way to know if the keyboard is needed (VNC, RDP clients). There are no keyboard only iOS devices, and all app developers knew from day 1 that devices were touch only, so we are in a slightly different position with needing to support both key and keyless devices, and activities that were written without touch input in mind... So I'm sure we will need a fallback button. Sayamindu device frame seems a good choice, once we have a touch gesture to reveal the frame that is ;) Anyone know what the planned physical buttons may be for the XO-3? If Sugar was native on iPad hardware, I'd certainly want the single home button to reveal the frame, with perhaps a double click of it switching to the Sugar favourites ring view. Regards, --Gary > --scott > > -- > ( http://cscott.net/ ) _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
