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

