On Mon, 21 Jul 2008 23:21:22 +0100 Al Johnson <[EMAIL PROTECTED]> babbled:
> 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? 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@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
