Event to Action Mapping
mailinglists at who-t.net
Sat Apr 14 05:07:13 PDT 2007
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
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.
Multi-Pointer X Server
More information about the xorg