Openmoko on Design
Carsten Haitzler (The Rasterman)
raster at openmoko.org
Wed Jul 30 03:32:19 CEST 2008
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>
More information about the community
mailing list