Event to Action Mapping

[Peter Hutterer]

On 12/04/2007, at 17:26 , Thorsten Wilms wrote:
> I understand that it would change the X-server's role, but console
> applications have mappings, too.
> But yeah, that's why I have 2 architecture alternatives
> http://thorwil.wordpress.com/#6.1.Architecture
applications don't handle input directly because input differs  
depending on the hardware. if you want to go in between X and the  
kernel, you need to provide hardware drivers.

> Could add a 3rd, where things happen above X, but applications
> don't handle input directly. Actually it is likely better to
> list those aspects seperately.
applications don't handle input directly in terms of hardware byte  
parsing byt they still receive fairly basic events. key press with a  
keycode is about as low-level as you can get.

> Yes, I have been seeing a library as one option or part of the
> solution, but wouldn't one also have to consider a daemon, an
> extension to X and/or extending WMs?

daemon/WM would be client applications. They would need to intercept  
all events, parse them, modify them, forward them on. Difficult to do  
with X's event delivery model. XEvIE allows you do to this to some  
extent but I haven't tested it in a long time.

extension to X is a different thing (i've been toying around with a  
similar albeit still very different idea).
so you add a new set of events to the X server. a copy event, a past  
event, etc. but where do you do the parsing from raw input events to  
these action events? where do you store the policy of what is passed  
on? how to you load such a policy into the server?

Now, a big question is: do you want these new events to work for any  
application or just for new applications that know about the events?  
The former is _a lot_ harder. The latter can - as I said - be done  
with a library.

Whatever you do, a prototype implemenation would strengthen your  
point a lot.

Cheers,
   Peter

--
Multi-Pointer X Server
http://wearables.unisa.edu.au/mpx