Re: [g-a-devel] gail: hands off ...

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:

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))

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 gail.

Gnome-accessibility-devel mailing list
Gnome-accessibility-devel gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]