scwm-devs

[Scwm-devs] event question

[Scott L. <sl...@cs...>]

I've been thinking about the event rewrite.  I'm trying to write
up a proposed interface to binding events based on the protocol
Greg suggested in the doc/dev directory.

I think we want to support the ability to bind key sequences
to actions.  I ran into a situation that I don't know what the
right behavior should be and I'd like opinions.

Suppose the user has bound a bunch of keys to "F1 <key>" where
they are basically using F1 as a prefix key for key events to
send to the window manager.  What do you think should happen
if they type "F1 b" where this key sequence has not been bound
to anything?  Should Scwm send "F1 b" to the application, send
"b" to the application, or drop the event on the floor?
Or should it do something else entirely?

- Scott

[Scwm-devs] Re: event question

[Greg B. <gj...@cs...>]

I'd use Emacs as a guide.  Try hitting something like C-c C-2 and you'll
see it complain "C-c C-@" is undefined.  Scwm could do that using a
popup message box for a user configurable amount of time.  Neither of
the keystrokes get inserted into the buffer.  (Just as Scwm wouldn't
send either to the application.)  The upshot of that is that prefix keys
should be non-app keys, but that's good sense, anyway.

Thanks,
Greg


Scott Lenser <sl...@cs...> writes:

> I've been thinking about the event rewrite.  I'm trying to write
> up a proposed interface to binding events based on the protocol
> Greg suggested in the doc/dev directory.
> 
> I think we want to support the ability to bind key sequences
> to actions.  I ran into a situation that I don't know what the
> right behavior should be and I'd like opinions.
> 
> Suppose the user has bound a bunch of keys to "F1 <key>" where
> they are basically using F1 as a prefix key for key events to
> send to the window manager.  What do you think should happen
> if they type "F1 b" where this key sequence has not been bound
> to anything?  Should Scwm send "F1 b" to the application, send
> "b" to the application, or drop the event on the floor?
> Or should it do something else entirely?
> 
> - Scott

Re: [Scwm-devs] Re: event question

[Scott L. <sl...@cs...>]

> I'd use Emacs as a guide.  Try hitting something like C-c C-2 and you'll
> see it complain "C-c C-@" is undefined.  Scwm could do that using a
> popup message box for a user configurable amount of time.  Neither of
> the keystrokes get inserted into the buffer.  (Just as Scwm wouldn't
> send either to the application.)  The upshot of that is that prefix keys
> should be non-app keys, but that's good sense, anyway.
> 
> Thanks,
> Greg
> 

I don't think the situation is entirely analogous since there is no question
of emacs passing the event on to the app.  In any case, I think that is the
most reasonable behavior.

There is an interesting side effect to this behavior.  If we follow the emacs
model of event maps are a single event deep and prefixes are handled by
going down to another event map, then the event maps act differently.

Consider, bindings like so:

event_map
  M-F1 => event_map
            M => maximize window
            m => minimize window
            i => iconify window

Now, if the user types "M-F1 j", a message displays saying this is not bound
and nothing else happens.  If the user type "j", then this gets sent on to
the application.  So in the first level event map, unbound events gets passed
through.  In the second level event map, unbound events cause a message to
be displayed.  The implementation in X calls is likely to be different too.
The first level event map will need to install a bunch of passive X grabs to
get its keys, but the second one will probably be handled with at least the
keyboard grabbed.  I suppose this distinction could be made when the event map
gets installed and thus hidden from the user.  It does create some interesting
problems, though.

- Scott

Re: [Scwm-devs] Re: event question

[Greg B. <gj...@cs...>]

I see your point.  But you can think of the first level event map as
containing bindings for "j" -> literal "j" to be passed to the
application (that's the way Emacs treats them -- X's implementation
makes it a little bit trickier to view things that way, but I think it
can still make sense conceptually).  FWIW, the closest place I came to
multi-key mappings is stuff like my H-p "shove-window" binding that pops
up a little visualization of a keyboard, grabs the keyboard, and lets
you hit another key.  I like this UI a bunch and it does exactly what I
expect and want.

Thanks,
Greg

Scott Lenser <sl...@cs...> writes:

> > I'd use Emacs as a guide.  Try hitting something like C-c C-2 and you'll
> > see it complain "C-c C-@" is undefined.  Scwm could do that using a
> > popup message box for a user configurable amount of time.  Neither of
> > the keystrokes get inserted into the buffer.  (Just as Scwm wouldn't
> > send either to the application.)  The upshot of that is that prefix keys
> > should be non-app keys, but that's good sense, anyway.
> > 
> > Thanks,
> > Greg
> > 
> 
> I don't think the situation is entirely analogous since there is no question
> of emacs passing the event on to the app.  In any case, I think that is the
> most reasonable behavior.
> 
> There is an interesting side effect to this behavior.  If we follow the emacs
> model of event maps are a single event deep and prefixes are handled by
> going down to another event map, then the event maps act differently.
> 
> Consider, bindings like so:
> 
> event_map
>   M-F1 => event_map
>             M => maximize window
>             m => minimize window
>             i => iconify window
> 
> Now, if the user types "M-F1 j", a message displays saying this is not bound
> and nothing else happens.  If the user type "j", then this gets sent on to
> the application.  So in the first level event map, unbound events gets passed
> through.  In the second level event map, unbound events cause a message to
> be displayed.  The implementation in X calls is likely to be different too.
> The first level event map will need to install a bunch of passive X grabs to
> get its keys, but the second one will probably be handled with at least the
> keyboard grabbed.  I suppose this distinction could be made when the event map
> gets installed and thus hidden from the user.  It does create some interesting
> problems, though.
> 
> - Scott