Re: Visual bell

[Havoc Pennington <hp redhat com>]

Bill Haneman <bill haneman sun com> writes: 
> The best approach (works for all apps and toolkits on an X desktop) is
> to listen for XkbBellNotify.  It probably should be user-configurable as
> to whether Metacity silences the 'audible bell' at the same time (by
> setting XkbAudibleBellMask to 0 in a call to XkbChangeEnabledControls).
> 
> Also it should be user-configurable as to what the visual bell does; I
> suggest the following options for starters:
> 
> 1) flash the screen;
> 2) flash the toplevel-window border of the window that sent the
> bell.

What is the use-case for 1), what is the use-case for 2)?  Or are we
just shotgunning all implementations we can think of and hoping one
works?

Or a better phrasing: what is the default and why? ;-)

> Note that the XkbBellNotify events have a "window" parameter that
> allows you to determine the origin of the bell (I suppose it could
> be 'None' in some cases, in which case perhaps the
> currently-focussed window or the topmost window could be flashed).

Hmm, s/in some cases/in almost all cases/ - many apps, including all
GNOME apps, are just using XBell(), not the XKB equivalent, right?

As you say "currently-focused window" is probably fine, it should be a
99%-OK heuristic.

> I attach a small C program that implements #1 above, as a standalone
> program.  I tried doing this in GTK+/GDK, so that I could make a
> Metacity patch, but it appears that GTK+ keeps XKB events to itself, by
> and large, and thus they are not available to a GdkFilterFunc (see
> gdkevents-x11.c).  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?

Havoc