Automatic pop up kbd

Carsten Haitzler (The Rasterman) raster at openmoko.org
Fri May 16 16:47:01 CEST 2008


On Fri, 16 May 2008 15:31:57 +0100 Chris Lord <chris at openedhand.com> babbled:

thats not the issue, there is auto-bringup if a widget is focused. bring-down
if no widget is focused. fair enough. that's good. saves a manual press
somewhere, but now there is no manual bringup or pop-down anymore. this means:

1. any app that does NOT send messages to root will never be able to get
keyboard input. every app now needs modification OR MUST use a modified
toolkit. so existing apps like scummvm or other sdl games or machine emulators
that also may know nothing about the state of the game and if it wants input or
not, have no way to do this without adding manual controls to each and every
app.

2. if it comes up because some entry widget HAPPENS to be focused, you have no
way to pop it down. eg - qtopia's notes app for starters. the whole window is
1 big multi-line entry widget. if the window is focused, the entry is focused.
that means the keyboard is ALWAYS up. if u want to scroll up and down and read a
note, but not type, you are stuck with 50% of your screen being eaten up by a
keyboard. like it or not. there is no choice. well ok - there is - specially
modifying all apps that behave like this so that you need to add an "edit"
button to enable/disable editing - now start adding that all over the place.
it's really silly when you can have 1 unobtrusive universal location for a
control that solves all these kind of cases.

this removes functionality for a user. it does not let them decide anymore.
they now have lost control.

> Hi all,
> 
> On Fri, 2008-05-16 at 21:26 +1000, Carsten Haitzler wrote:
> > On Fri, 16 May 2008 11:02:03 +0100 Andy Powell <openmoko at automated.it>
> > babbled:
> > 
> > > On Friday 16 May 2008 10:46, Carsten Haitzler wrote:
> > > > On Fri, 16 May 2008 10:33:13 +0100 Andy Powell <openmoko at automated.it> 
> > > babbled:
> > > > > Please can you make it possible to switch this off and / or
> > force the
> > > > > keyboard to hide. There's nothing worse than having an external
> > keyboard
> > > > > connected and being forced to waste screen real estate on
> > something you
> > > > > don;t need.
> > > >
> > > > design decision was made to remove manual control even though it
> > has been
> > > > there from the beginning. no can do.
> > > 
> > > is that code for 'someone just decided it shouldn't be there, we all
> > said it 
> > > should but they just told us to get rid of it'?
> > 
> > no comment :)
> 
> I initially wrote the multitap-pad with no instruction or input from
> anyone (I'd noticed that no one had any interest in creating a sane
> input method for a phone and figured one would eventually be necessary):
> http://chrislord.net/blog/Software/multitap-pad.enlighten
> 
> With that in mind, it's not a case of "someone just decided it shouldn't
> be there, we all said it should but they just told us to get rid of
> it'?", it's a case of "no one actually designated anyone to work on an
> input method, or if they did, that work was never done".
> 
> In my opinion, I have no idea why you'd ever want to manually
> enable/disable the input, unless some other design issue was causing
> this wish. To back me up, I'll point out that zero touch-screen phones
> have the ability to manually disable automatic input-method display.
> 
> This is just my opinion though. There's no technical reason that makes
> this hard, however - the code for the multi-tap pad is very few lines
> and pretty simple stuff
> ( http://svn.o-hand.com/repos/misc/trunk/multitap-pad/src/multitap-pad-main.c ),
> instead of complaining about decisions being made that conflict with your
> wishes, you could focus that energy on writing a patch.
> 
> If I were to write this patch, I'd suggest adding a boolean gconf key,
> something like '/desktop/poky/interface/auto_show_im' and add the
> necessary code in multitap-pad-main.c to listen to this key. This would
> require very few additions to the code (of course, adding some interface
> to configure this option and so on is another issue).
> 
> Hope that helps explain a few things.
> 
> --Chris
> 
> p.s. Not having a button on the actual keypad to hide the pad was an
> oversight, however, that should probably be there...
> 
> 


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>



More information about the openmoko-devel mailing list