On Monday 21 July 2008, Carsten Haitzler wrote: > On Mon, 21 Jul 2008 22:32:47 +0100 Al Johnson > <[EMAIL PROTECTED]> > > 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...) _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
