Event to Action Mapping

[Thorsten Wilms]

For what ever reason, this mail made it to my inbox only now, 
on Monday.

On Sat, Apr 14, 2007 at 09:37:13PM +0930, Peter Hutterer wrote:

> 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.

Well, all pointer events have to go to the X server anyway.
The only reason I would want something below X is to make 
mapping work for console apps. I want the ability to change 
their mappings if they run in an X terminal, and it would be 
bad if they behave differently outside X, then.

I guess the solution for the console could be a different one, 
somewhat comparable to the gpm/X situation.

Perhaps the driver part of X could be "split off"?
 

> 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?

I did not have Action Events in mind.

In the current state of my concepts, a set of Input Events that is 
handled as unity is called a Gesture. So both a single keystroke or 
a shortcut would be Gestures.

A single Mapping ties a Gesture to an Action with a Relation.
The Relation is about what exactly shall happen. In the most 
simple case, the Relation is of the Trigger type, calling an 
Action without argument.

So I need a parser from Input Event to Gestures.
Then a mechanism to trigger Actions.

For managing/editing Mappings, an Action Store is needed already. 
Applications/packages  should put information about their Action into 
the Store on installation, I think.

But for triggering, not all Actions from all installed applications 
are of interest, but only those that are available (application 
is running and in the right state). There could be cases of Gestures 
mapped to several Actions, where the first that is available should 
be triggered. Don't know how to handle that, yet.


> 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.

The final goal would be all applications working with the mapping 
system. But there needs to be a realistic way to get there.
The mapping system could deal with fixed mappings for old apps, 
but the information has to come from somewhere.
Old application could be fed with faked events to allow their 
mappings to be changed, but mnemonics and shortcuts listed in the 
menus and documentation would be a problem.


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

Yes :/
I don't have the skill to implement such a thing now and not the 
time for learning and training to get there.
My plan is to apply the skills I have as a designer to define the 
What, Why and to some extend How in a way that hopefully will get 
other people on board. I know that what I have now is not enough.
 

> Cheers,
>   Peter

Thanks.


-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com