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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Oct 19 04:37:27 PDT 2009


--- Comment #3 from Alejandro PiƱeiro <apinheiro at igalia.com>  2009-10-19 04:37:27 PDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > I'm missing any reason to consider that we are in a different toolkit?
> Yes. :-)
> For any app for which there is not a specific, custom script in Orca, Orca
> queries the app to determine what toolkit is being used. How WebKit implements
> things is in some cases quite different from how the same things would be
> implemented by a Gtk+ app. If WebKit claims to be Gail, Orca's default script
> will handle things, and it will handle them wrong.
> Does this make sense??

Yes, know I understand the reasons. Thanks.

Anyway, and probably just a nitpick, my concern about redefine toolkit_name and
toolkit_version is because, as I said in my previous comment, there isn't a new
toolkit here, so redefine the toolkit_name as "Webkit" is just a hack hint for
the AT applications (like Orca).

But I also understand that from the POV of Orca would be more easy to implement
a lot of things, as Webkit will not be tied to one specific application (it
would be used for epiphany, devhelp, and so on) so it has sense to share it.
The other option, quick-thought, would be have a epiphany, devhelp and so on
scripts, all of them calling common python scripts, but the problem is that if
it appears a new Gtk+ using WebKitWebView, it wouldn't use the specific Orca
scripts without updating Orca.

Probably the best option to solve that is just redefine toolkit_name as you
suggest, perhaps any others (Xan?) have their own opinion.

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

More information about the webkit-unassigned mailing list