Terminal for ASU

[Carsten Haitzler (The Rasterman)]

On Mon, 21 Jul 2008 23:21:22 +0100 Al Johnson <openmoko at mazikeen.demon.co.uk>
babbled:

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

it says nothing... not specified as a design parameter. :) (another good reason
for a manual overried until auto-detection of a bt/usb keyboard is flawless.
even with a bt keyboard - it may be on, in your pocket or bag, but you may not
want to use it.. thus want a manual "give me a virtual keyboard anyway - bt
keyboard there or not". :)

i'm with you on this and i understand why an automatic keyboard is goo d(no
need to always manually bring it up when you'd want it anyway), but manual
control is going to be needed for a long time to come as it may never always
automatically do it right for you... :)

> > 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...)
> 
> 
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


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