GNOME Bugzilla – Bug 167783
gnome-terminal should be able to beep the right window
Last modified: 2008-09-25 14:36:24 UTC
Please describe the problem: when visual feedback to flash window titlebar, flash window that focus currently not bell source window. Steps to reproduce: 0. set "Visual feedback" to "Flash Window titlebar" in gnome-sound-properties 1. make two xterm 2. type sleep 5 && echo -n "\a" && sleep 1 && echo -n "\a" in first xterm and run 3. focus to the other xterm. Actual results: flash the other xterm. Expected results: flash first xterm. Does this happen every time? yes Other information:
Reproduction steps don't appear to work under bash but do work under tcsh. From the description of /apps/metacity/general/visual_bell_type: If the application which sent the bell is unknown (as is usually the case for the default "system beep"), the currently focused window's titlebar is flashed. Havoc: Does that mean this is NOTABUG?
It's a bug in the terminal being used, so either gnome-terminal or NOTGNOME Terminal should be able to beep the right window.
I was able to duplicate under gnome-terminal, so I'll reassign there.
Created attachment 71854 [details] [review] Fix the beeping issue, *if* my patch in bug #353455 gets accepted. When vte gets a BELL character it calls gdk_display_beep on the display to which the terminal widget is attached. Looking at metacity's bell.c, one sees that in that case the currently focused window gets flashed. The correct way to fix this is to add API to GDK to beep a *window* instead of a display. I've posted a patch on bug #353455 which does this. _Assuming_that_gets_commited_, then the following patch fixes this issue on vte's side. If GDK people do not like my gdk_window_beep thingie, then vte should do itself the whole thing.
Mariano is back! Yaay!!! :-)
and even fixing vte stuff :-)
yay, can't wait until we branch...
GDK accepted the patch, so this should be accepted-commit_after_freeze?
(In reply to comment #8) > GDK accepted the patch, so this should be accepted-commit_after_freeze? As soon as you can require a version of gtk+ that contains the new API. Or conditionally use the new API. There's another bug open on gnome-terminal about setting X urgency hint on receiving a bell. Not sure if we can rely on the window manager doing that now.
Mariano or Elijah, (checking the patch,) what if toplevel is not windows and the condition fails? Should it fall back to the old behavior?
Um, sure? I'm having a hard time thinking of when the condition would fail, but it seems that the old behavior would be a reasonable fallback.
Well, a condition that can't fail doesn't make sense either :). I'll update and commit then.
Should go in 0.17.x. I'm releasing 0.16.10 today, but plan on bumping Gtk+ requirement and add/remove api after.
Looks like a dup of bug 329108 (this one is older but the new one has a more correct patch).
*** This bug has been marked as a duplicate of 329108 ***