some UI and text input thoughts

[Carsten Haitzler (The Rasterman)]

On Wed, 14 Jan 2009 10:01:20 +0000 Andy Green <andy at openmoko.com> babbled:

nothing to do with hardware here - all to do with software stack. the fact is
there is no generic "zoom" control for apps - and apps have no concept of one.
you also need to think about where in the stack you sit - if you go
to /dev/input... you will be doing your own driver work specific to 1 hardware
type - if that changes - you are going to have to adapt. the best bet is to do
this higher up at the x level - but here you hit a problem. mouse events ONLY
go to the window they are on (or to who grabbed the mouse). so in this case
every app/toolkit needs to handle these themselves - OR you uxe an extension
like xevie and we put in an indirector for all events - this indirector
can/will be responsible for:

1. filtering (removing events, delaying and getting rid of garbage - it it
wants)
2. selectively passing along some events and not others possibly with
modifications (eg translate/scale the input/output - needed for a compositor if
you do things like scale the window output in the compositor)
3. can interpret series of events into gestures and then produce some form of
message (the protocol and standard are yet to be defined) that can be sent to
the root window o the focused window - or possibly just execute some command
etc. etc.

:)

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Somebody in the thread at some point said:
> 
> | Are there any hardware engineers who can verify whether or not the
> | touch-screen on the Neo or FR could register or generate motion-based
> | events? If not, is this something that could be done easily in
> | userspace (i.e. inputproto)?
> 
> You can just have an app eat /dev/input/event1 and figure out if it sees
> such an action in the necessary timeframe to be a gesture, it won't
> upset any other user of /dev/input/event1.  Not sure where tslib
> calibration fits in there but I guess for your purpose, you don't really
> care since it is not associated with any absolute coordinate.
> 
> - -Andy
> 
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkltt/AACgkQOjLpvpq7dMpVxwCcCIdp3N8H+MAk2n6PQUCenclx
> IjkAn0UN88xsER95XUbfh7chjj3ye0z6
> =bluP
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> devel mailing list
> devel at lists.openmoko.org
> https://lists.openmoko.org/mailman/listinfo/devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com