[Webkit-unassigned] [Bug 30500] [Gtk] Implement atk_get_toolkit_name and atk_get_toolkit_version

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30500





--- Comment #1 from Alejandro Piñeiro <apinheiro at igalia.com>  2009-10-19 03:49:35 PDT ---
I haven't tested it, but I suppose that right now, it is returning as toolkit
name, GAIL. Right?

As far as I know, the gtk accessibility support in WebKit is not defining a new
AtkUtil at all. It is just a new AtkObject that works as a wrapper of the
internal a11y support in Webkit.

It is just the a11y support for a specific Gtk Widget, so I don't understand
why this require to explicitly say that the toolkit is Webkit (as I really
think that we are not in a different toolkit).

I think that you are asking it because in the Gecko implementation, it returns
as toolkit "Gecko". But this is different:
  * Gecko defines a new AtkUtil implementation (see nsAppRootAccessible)
  * It redefines get_root, returning a different root (gail_root if not
possible)
     * AFAIK, this doesn't happens with Webkit, Webkit always return the gail
root.
  * It wraps the event management, as the "window:" signal can also be emitted
by MaiAtkObject.
  * Other issues

So, in this case Gecko is defining a new toolkit (the root is different) that
wraps part of their functionality on Gail.

But this is not the case with Webkit. The Webkit a11y support is just implement
the Atk interfaces in a new Gtk widget. Technically (IMHO) this doesn't mean a
new toolkit, it is just a "library" that defines a new gtk widget that requires
a11y support. The main point of that is that Webkit is not defining a new
get_root method. So I think that the correct toolkit is GAIL.

I'm missing any reason to consider that we are in a different toolkit?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.