Automatic pop up kbd

Carsten Haitzler (The Rasterman) raster at openmoko.org
Fri May 16 18:50:07 CEST 2008


On Fri, 16 May 2008 17:30:08 +0100 Chris Lord <chris at openedhand.com> babbled:

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

you remove manual controls once all automatic controls are working everywhere.
you don't remove them and then think about "oh - we haven't got automatic
controls done yet". removing the control didn't buy anything but removal of a
button in an area already blank and allocated as empty space. we could argue
validly it might be better hidden further away and not in plain sight - but
total removal is silly. and i disagree with your assessment of hildon. forcing
changes on apps when not needed is bad. it creates work where non is actually
needed. if removing the control bought something in return it'd be a weight up
of a balance of positive vs negative result. as it stands it bought nothing
(beyond possibly not confusing people - but hell. that's the least concern. i
challenge people to wonder how to out in a return or a space... or change
layouts! behavior has been mostly imitated from the qtopia predictive
keyboard, but this is what was requested, so an "obvious" keyboard button now
is gone and instead you need to know that swiping your finger to the right
enters a space and goes to the next word... know that wipe-to-left is
backspace. nothing on screen hints or tells you this, so u'd better read the
documentation).

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

as there was already a show/hide button, on the top-left of the screen this was
unnecessary and left more room for word corrections/completions.

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

and an automatic car STILL provides manual gears you can shift - not just "D"
but "3", "2" and "1" for when the auto just won't guess right. as it stands
this is the same as a gearbox with only "D". :)

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


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



More information about the openmoko-devel mailing list