Yes, I believe they should-- however, I'm guessing we really need some
system wide setting that lets the user decide what the "system beep"
actually means, as for example a deaf user will need a visual
indication rather than an audio one.  I'm not sure if such a mechanism
currently exists in gtk/GNOME.

Moving non-critical and hard-to-fix bugs to 2.0.2

Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.

This can be dealt with through Xkb ... it provides a mechanism
for an application to implement custom handling for XBell()

(Just adding comments in response to Owen's recent "should we fix 
for 2.2" email)

Now that a visual bell seems close to being reality (see recent 
discussions on desktop-devel-list), I think the issue of beeping in 
text and other widgets (like lists) when the user tries to navigate 
beyond their bounds is worth considering again.  This is part of 
Windows accessibility guidelines so users with accessibility needs 
who are migrating from a Windows desktop will expect it.

Punting, since I don't think we have a definition of the
complete set of circumstances where a beep should occur.

The keynav spec does mention it everywhere we'd want it, I think, but
I'm happy to punt it until we've given the doc the overhaul and
re-appraisal it so badly needs :)

Updating status_whiteboard field to reflect A11Y team's assessment 
of accessibility impact.

Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME
bug list :)

*** Bug 142791 has been marked as a duplicate of this bug. ***

We should incorporate this into the keynav guidelines.

I think that any time a navigation or deletion event (destructive backspace, or
navigation) past end-of-buffer or beginning-of-buffer occurs in response to a
user command, a beep should be issued.

AP4 was too low for this bug - especially since it's part of the Windows
guidelines, and something many users (with or without disabilities) will have
come to expect.

Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs.
 Filter on "SUN A11Y SPAM" to ignore.

I'd like to make sure we've checked other platforms to make sure that we
are reasonably consistent with what they are doing here. Beeping a lot
isn't really "user friendly" - consider that a lot of users will hold
down the delete key to delete the entire buffer.

For that particular case, couldn't you just beep once for the first 'nothing
left to delete' occurrence, and not beep again until the user released and
re-pressed the Delete key?  Or do what my Powerbook manages to do in
gnome-terminal and make a single continuous beep until you release Delete...
great for playing little tunes :)

Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.

See bug #322640 for a more general solution of "keynav failed".

Fixed in CVS. Bug reporters, please check your use cases and file
new bugs against the new features if anything doesn't work. It doesn't
make sense to keep 6 bugs open.

2006-11-16  Michael Natterer  <mitch@imendio.com>

	Add new infrastructure for notifications of failed keyboard
	navigation and navigation with restricted set of keys.

	The patch handles configurable beeping, navigating the GUI with
	cursor keys only (as in phone environments), and configurable
	wrap-around. Fixes bugs #322640, #70986, #318827, #334726, #334742
	and #309291.

	* gtk/gtksettings.c: added properties gtk-keynav-cursor-only,
	gtk-keynav-wrap-around and gtk-error-bell.

	* gtk/gtkwidget.[ch]: added new signal "keynav-failed" and public
	API to emit it. Added New function gtk_widget_error_bell() which
	looks at the gtk-error-bell setting and calls gdk_window_beep()
	accordingly.

	* gtk/gtk.symbols: add the new widget symbols.

	* gtk/gtkcellrendereraccel.c
	* gtk/gtkimcontextsimple.c
	* gtk/gtkmenu.c
	* gtk/gtknotebook.c: use gtk_widget_error_bell() or look at the
	gtk-error-bell setting instead of calling gdk_display_beep()
	unconditionally.

	* gtk/gtkcombobox.c
	* gtk/gtkentry.c
	* gtk/gtkiconview.c
	* gtk/gtklabel.c
	* gtk/gtkmenushell.c
	* gtk/gtkspinbutton.c
	* gtk/gtktextview.c
	* gtk/gtktreeview.c: call gtk_widget_error_bell() on failed keynav.

	* gtk/gtkentry.c
	* gtk/gtklabel.c
	* gtk/gtkrange.c
	* gtk/gtktextview.c: consult gtk_widget_keynav_failed() on failed
	cursor navigation and leave the widget if it returns FALSE.

	* gtk/gtkmenushell.c
	* gtk/gtknotebook.c: only wrap around if gtk-keynav-wrap-around
	is TRUE.

	* gtk/gtkradiobutton.c: ask gtk_widget_keynav_failed() to decide
	whether to to wrap-around, and don't select active items on cursor
	navigation if gtk-keynav-cursor-only is TRUE. Should look at
	gtk-keynav-wrap-around too, will look into that.

Has someone actually tried using a gtk text editor with this beeping? Has someone tried to address the concerns about beeping a lot? It's nice that widgets beep consistently, but it beeps like crazy!
Does it beep because "if it doesn't beep, and focus doesn't move, then user will be confused?" I.e. is beeping added because some other feature is implemented/not implemented, not because someone actually think beeping is good?