Terminal for ASU

[Carsten Haitzler (The Rasterman)]

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

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

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