Event to Action Mapping
t_w_ at freenet.de
Mon Apr 16 02:15:35 PDT 2007
For what ever reason, this mail made it to my inbox only now,
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.
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.
Thorwil's Design for Free Software:
More information about the xorg