Openmoko on Design

[Carsten Haitzler (The Rasterman)]

On Tue, 29 Jul 2008 20:56:23 -0400 Daniel Benoy <daniel at benoy.name> babbled:

> Is it feasible to have illume detect that an application isn't 
> capable/interested in sending the signal to bring up the keyboard?

with the matchbox protocol - it is not possible. with the new protocol i put in
(which uses window properties) it is possible to know. the app will explicitly
set a property on its window indicating its desired keyboard state.

> Also, would the openmoko design team be willing to consider a  toggle in the 
> configuration menu between manual and automatic?
> 
> I have a portable bluetooth keyboard (Something which I assume the design
> team wants to eventually support out-of-the-box) and it's annoying for the on 
> screen keyboard to ever come up for me unless I specifically ask for it 
> because it reduces my usable window space, so in my case, I would prefer to 
> set it to manual. (And I have modified my illume theme to achieve that)

actually i just committed code that "in theory" detects extra keyboards (bt,
usb - not tested) and forcibly disables and vkbd if you have one attached. i
know - it'd be nice to even have this behavior a conifg value and able to be
overridden... that's a matter of code - enough of it, but for now, it probably
covers 99% of use cases in the event of a bt/usb kbd... but as i said - it's
untested right now (it works - if i fake it - so the code works, but detection
of the keyboard is still untested - it should work... in theory).

it's in latest rev of illume in svn, no nightly build or update to asu.dev
git... yet... will do soon.

> If I didn't have a bluetooth keyboard, I'd prefer for it to be automatic, but 
> provide me with a manual toggle (automatically) when I'm currently looking at 
> software which doesn't know how to ask for the keyboard..
> 
> I think this is a good compromise, and in the best interests of the platform 
> because of the value of quick-and-dirty linux X11 application porting, but at 
> the same time end-consumers who only use pre-installed software will never 
> even know the toggle is there, so the designers should be happy.
> 
> I hope I'm not adding to the flame war :(  I really appreciate the hard work 
> and money that openmoko is putting into this project for me and the rest of 
> the community .. and I don't want them to feel underappreciated as a result 
> of all the nitpicks.

it's up to the designers to say if they want it or not. me - personally, agree.
i also don't see the harm in keeping the toggle if the app can do it
automatically anyway - as you may not want to edit anything - just browse (eg
web browser - the javascript forces a editable field to be focused - thus the
kbd pops up - but you have no desire to edit - you just want to read... so tap
the button to pop it down). but that's just my opinion.

> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


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