Re: [g-a-devel] gail: hands off ...
- From: Bill Haneman <Bill Haneman Sun COM>
- To: Oliver Braun <Oliver Braun Sun COM>
- Cc: accessibility mailing list <gnome-accessibility-devel gnome org>, michael meeks novell com
- Subject: Re: [g-a-devel] gail: hands off ...
- Date: Wed, 09 Nov 2005 10:27:56 +0000
BTW guys, I'm looking into this now.
I have some concerns about this approach - in an ideal world, gail
should not be making bogus assumptions about GailObject subclass
behavior. *If feasible* I'd rather fix the assumptions in gail in some
spots, possibly modifying the OOo bridge to comply with a few expected
behaviors in others, and use a more specific hinting mechanism from the
OOo peer system.
Event notifications and behavior are one of the areas where ATs and
their state model get fragile. That's one reason why there's downside
to making 'custom widgets' and toolkits solely responsible for their
event emission; we want to keep the event code as centralized as is
technically feasible, and share as much implementation as humanly possible.
Oliver Braun wrote:
michael meeks wrote:
Other sources of problems are "show", "window-state-event" and
"configure-event" signal emission hooks: the OOo windows to filter
(sub menu and combobox popups) return NULL when asked for an
accessible, which is treated like an error by the signal hook code in
On Fri, 2005-11-04 at 16:16 +0000, Bill Haneman wrote:
I don't see the problem (yet); I looked at gail_focus_watcher() and
don't see anything that assumes that the object in question is a
GailWidget or GailObject subclass, only that the peer is a
GtkWidget. Maybe the problem is visible in one of the other
emission hooks instead?
Well - eg. in the selection listener - from a 2 second glance:
else if (window->type == GTK_WINDOW_POPUP)
GtkWidget *child = gtk_bin_get_child (GTK_BIN (widget));
if (GTK_IS_WIDGET (child) && GTK_WIDGET_HAS_GRAB (child))
Gnome-accessibility-devel mailing list
Gnome-accessibility-devel gnome org
] [Thread Prev