sawfish: How to read all necessary key events, and nothing more

Original (and messy) text was sent to the sawfish ML. Here much improved.

How to grab (keys)

passive grabs cannot be asynchronous (in general):

This gives little control in case the invoked command decides to grab actively; it may be too late, because other key events have already been distributed to the focused window.

neither synchro passive grabs are enough.

the grab ends with the release of the grabbed key. That means that if we grab H-i, this sequence (which might occur if i type quickly) Hyper-press, i-press, Hyper-Release, e-Press, i-Release will deliver the "e-press" to the grabber. This is undesired! But it can occur by mistake (wrong synchronization of fingers).

I think, that this is a non-intended feature, but i don't know of any proposal for different behaviour.

SUMMARY: we have to grab passively synchro, and once the

How to allow-events (i.e. request more key events)

If the lisp code has a possibility to grab-keyboard, it seems plausible, that the C code should not disregard it, and should not run `allow-events' `ungrab-keyboard' without precise rules.

We must use only synchronous allow-events.

C part must coordinate with lisp on reading next event:

OTOH, i want to isolate the lisp code from some boring tasks:

C might take care about skipping over modifier events, key-releases. C is told what to do through keymaps, 2 variables eval-key-release-events and eval_modifier_events and the unbound-key-hook.

My reasoning is this: If lisp requests more key events, and eval-key-release-events or eval-modifier-events indicate that lisp is not interested in an arrived event (because it is a modifier, or a keyRelease), the C code should request the next event.

Summary: Lisp defines what considers an event, and

note: there is currently no way to grab keyboard and prevent C from calling any XAllowEvent. There is code for it, and once I used it (to freeze the keyboard for some time), but since then i changed the lisp--C synchronization and didn't update this feature.

When to ungrab?

As i explained above, we have to ungrab explicitely, instead of using "passive" key grab. Also, ungrabbing has to be synchronized with change of focused window: we ungrab "into" a certain window. We don't want any following key-events to be delivered to the previously focused window, or any other random window.

So the (possible) XSetInputFocus must be issued before XUngrabKeyboard. And since C postpones the XSetInputFocus, the lisp code must delegate the C part for (postponed) ungrabbing as well.

I added another variable: grab-counter

ungrab_into_focused_window

high level lisp api:

• grab-keyboard-soft #!optional (window nil) (ptr-sync #f) (kbd-sync #t) increments the counter. Moreover, it issues grab-keyboard. This is for the situation, when you try a function from repl. This might be avoided probably, if C set/unset a variable to mark its grabbing.
• ungrab-keyboard-soft decrements the counter.
• call-with-keyboard-grabbed thunk in mainline SF! but now bettter: protects thunk w/ counter increased
• call-with-keyboard-grabbed* thunk args same, but args pushed to the grab-keyboard-soft

All these function are ready to be used from repl.

• read-event is ok now.

Please note, that when entering (recursive-edit) you have to (allow-events 'sync-keyboard) before, from lisp! The usual C part does not follow! This needs fix.

links:

http://www.std.org/~msm/common/protocol.pdf

Key-processor

new feature to have a look on key events before C processes them.