Terminal for ASU

Al Johnson openmoko at mazikeen.demon.co.uk
Tue Jul 22 00:21:22 CEST 2008


On Monday 21 July 2008, Carsten Haitzler wrote:
> On Mon, 21 Jul 2008 22:32:47 +0100 Al Johnson
> <openmoko at mazikeen.demon.co.uk>
>
> babbled:
> > On Monday 21 July 2008, Carsten Haitzler wrote:
> > > the problem is the designers decided that ASU is not to have any manual
> > > keyboard toggle button because it will disturb the design and/or
> > > confuse users, so all apps and toolkits need modification to talk a
> > > "protocol" to bring up the keyboard on demand (no manual controls).
> > > that is why you need to do this. personally i think you need a manual
> > > control because, as such, many apps and toolkits will not be changed,
> > > or they will get it wrong and give you a keyboard when you don't want
> > > one, or decide not to give you one when you do... but that's not my
> > > call.
> >
> > The designers' idea is great, but in practise I suspect you're right.
> > Please can we at least have a manual override as a configure option, even
> > if it's not on by default?
>
> sorry. "not in the design". it's not specified as a config option. i'm only
> doing what's in the spec as there is much unhappiness if i do otherwise. if
> you REALLY want the button you will have to hack the theme to put it back
> in (as its just a theme element that emits a signal when pressed).

GRR...defective by design. You've made a fair summary of my feelings on 
automated keyboards too. So what does the spec say about when there's another 
input device like a bluetooth or USB keyboard?

> yes automatic keyboard popup is good, but we don't live in a world where we
> can guarantee and force every app to behave perfectly. lots of things are
> "ported" (recompiled) and forcing them to add patches to bring up keyboards
> is just yet another barrier to porting and leaves us with less software :(
>
> even though automatic cars are ... automatic - they STILL have manual gears
> you can use - auto doesn't always get it right! :) 100% auto should only be
> considered once there is nothing left alive that ever could need a manual
> override. we are very far from that reality :(
>
> (as such the protocol used by matchbox keyboard/multi-tap is very error
> prone as anyone can send a message and the keyboard can be left in all
> sorts of erroneous states. the property-based one i implemented is reliable
> as the keyboard state desire is a property of the windows - thus the
> focused window's keyboard property determines if keyboard should be there
> or not, but this so far is a private protocol implemented by e. it is not
> documented, nor has it been standardised. all of this should go to
> freedesktop.org and be proposed as wm-spec extensions for "mobile devices"
> and then adopted, specified, and implemented everywhere, tested well,
> then.. when all this is done.. the manual button may have a chance of being
> removed...)






More information about the community mailing list