Automatic pop up kbd

Chris Lord chris at openedhand.com
Fri May 16 18:30:08 CEST 2008


On Sat, 2008-05-17 at 00:47 +1000, Carsten Haitzler wrote:
> 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.

So to reduce coding work, we want to add awkward/remove nice features?
Case in point, maemo/hildon require a fair amount of changes to
integrate correctly, but they went ahead with things all the same and
the user experience is better for it. If apps don't integrate with the
platform, those apps should be changed - sure, make allowances to make
these changes easier, but in my opinion, crippling (sorry, this is too
strong a word, but I couldn't think of a better one) the user experience
isn't something you should do to support legacy applications.

> 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.

You'll notice in the 'p.s.' at the end of my original mail that I
thought not having a hide button on the pad was an oversight.

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

There's such a thing as having too much control. I appreciate the power
steering in my car, even if it removes an amount of control.

--Chris

> > 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...
> > 
> > 
> 
> 




More information about the openmoko-devel mailing list