Automatic pop up kbd

Chris Lord chris at openedhand.com
Fri May 16 18:24:49 CEST 2008


On Fri, 2008-05-16 at 16:16 +0100, Andy Powell wrote:
> On Friday 16 May 2008 15:31, Chris Lord wrote:
> > 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.
> 
> Then I guess you didn't actually read what I wrote then, here it is again:
> 
> "There's nothing worse than having an external keyboard connected and being 
> forced to waste screen real estate on something you don;t need."

Sorry, I missed this - I agree.

> It's also particularly annoying when a keyboard pops up on the first field of 
> a screen covering up the actual field you wanted to fill out, unless the 
> keypad provides tab navigation or something.

The keyboard should only come up when the user explicitly selects an
input entry - of course, this is up to the application to make sure it
doesn't force the keyboard up by auto-focusing an entry. Or up to the
toolkit that it doesn't fire off the X event when an entry isn't focused
explicitly. Not the keyboard, anyway.

> <snip>
> > (
> > 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.
> 
> Actually, it was a request at first, it only became a complaint when choice 
> was taken away. 

Who took the choice away? (I'm not in charge of OpenMoko or what patches
get accepted of course, so maybe someone did, but I've not been aware of
this?)

> > 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).
> 
> Yes, both of which are pretty trivial, but that wasn't the point I was making.
> 
> > Hope that helps explain a few things.
> 
> It only explains that you seemed to think I was saying your keyboard was shit 
> or something. We aren't even talking about your keyboard.  Carsten has 
> provided a mechanism we can use to fix his keyboard when it appears. 

In fairness, it is pretty shit, it was only meant as a starting point
and it's mostly just tying together other peoples' work with string and
masking tape :) But it sounded to me like blame was being attributed
when there was no one/thing at fault?

--Chris





More information about the openmoko-devel mailing list