Re: Visual bell

[Bill Haneman <bill haneman sun com>]

On Tue, 2002-10-22 at 00:54, Jody Goldberg wrote:
... (bill wrote)
> > > Perhaps you and Owen could agree to a small GDK patch
> > > that would propagate XKB events to filter-clients, in which case you
> > > could trap them in Metacity's filterfunc.  Otherwise, you will have to
> > > open your own connection to the XServer :-(
> > 
> > It looks OK to me? Owen was this changed in 2.1.x or something?
> 
> huh?
> 
> gtk filter functions work smoothly with XKB events in 2.0 and 2.1.

Hmm, maybe I am misreading something.  When I tried trapping XKB events
with GdkFilterFunc, I saw none.  On examining the gdkx11-events.x file,
I found the following switch statement:


    default:
#ifdef HAVE_XKB
      if (xevent->type == display_x11->xkb_event_type)
	{
	  XkbEvent *xkb_event = (XkbEvent *)xevent;

	  switch (xkb_event->any.xkb_type)
	    {
	    case XkbMapNotify:
	      _gdk_keymap_keys_changed (display);

	      return_val = FALSE;
	      break;
	      
	    case XkbStateNotify:
	      _gdk_keymap_state_changed (display);
	      break;
	    }
	}
      else
#endif
	{
	  /* something else - (e.g., a Xinput event) */
... etc.

which appears not to pass XKB events to client (except for
XkbStateNotify events).  Of course this is in gdk_event_translate, a
1200+-line nest of switch statements, so I may have missed something. 
On looking at it again, it might work with a global filter func, but
then I would get multiple notifications (since the XKB bell notification
is already global, and we don't want to consume the event).  So I think
the right thing is a small change to the HAVE_XKB block, so that the
event is passed to non-global filter functions.

Owen?

The conditional inclusion is important, yes. If we use GdkFilterFunc it
matters not, since we won't get XKB events unless the extension is on. 
Visual bell won't work without it, of course.

-Bill

> That is what we use in the gnome-settings-daemon.  You do need to do
> a touch of X magic to find the event id for the extension, but the
> amount of code is pretty trivial and easily compartmentalized.  The
> only other ugliness is the 2 fold checking that
>     - you can compile the Xkb code
>     - the user's server supports it.  Note that the majority of Sun
>       users have massively broken XKB implementations, so this is
>       not a corner case to be ignored.