Basically our new-atk redesign of our Linux a11y support depends on something called AtkHyperlinkImpl. Without that it won't work. We simply won't be accessible on desktops with older versions of ATK. That's the cutoff we want and need to make. Accessibility on Linux is still bleeding edge, and we should avoid extra work making things work on older versions of Linux.
Created attachment 232872 [details] [diff] [review] patch Also clean up unused variables, typedefs.
Assignee: nobody → ginn.chen
Status: NEW → ASSIGNED
Ginn, does it make sense for us to set the accessible name for the app or window to something like "Accessibility in [appname] requires ATK [versionrequired] or later. Please check with your system vendor to get the latest library." Would the screen reader then at least read that so the user knows why it's not working? I realize this would require localization, but my question is -- how will a user know otherwise why it's not working?
I have the same question. I'm wondering what's the proper way to let user know.
Ginn, if we link against libatk directly via gtk2libs, then why does the user even need a recent version of libatk on their system? Or is the dynamic check really testing what has been linked with?
Comment on attachment 232872 [details] [diff] [review] patch Ginn is going to look into an alternative approach where we define symbols if the headers aren't recent. This should work since ATK is linked dynamically at runtime.
Created attachment 234192 [details] [diff] [review] make a11y build with old atk header Copy some defines into mozilla code to make Firefox build with old atk header file Firefox will have these new atk features if it is run on GNOME 2.16. (atk above 1.12.1) It won't crash on GNOME 2.14 or below. Is there a licensing issue?
Summary: [atk]Do not initialize a11y module if libatk < 1.12.1 → [atk]Build properly when libatk < 1.12.1 on build platform
Created attachment 234743 [details] [diff] [review] patch v2 To use header files in other-licenses/atk-1.0; Atk header files are in a separate diff file.
Attachment #234743 - Flags: review?
Attachment #234743 - Flags: review? → review?(aaronleventhal)
Created attachment 234744 [details] [diff] [review] ATK 1.12.1 headers
Attachment #234744 - Flags: review?(aaronleventhal)
Comment on attachment 234743 [details] [diff] [review] patch v2 Ginn, my biggest concern is, don't we now need the dynamic ATK library check? We would set the window title if ATK or AT-SPI is not recent enough for Firefox a11y. If we don't do that, it will either crash or just not work right, and confuse the user. That seems missing and I don't think we should check in without the dynamic check. Ginn, also do we need to have a separate atk-1.0 directory? I'd say put it directly in other-licenses/atk, because we might eventually update to atk-2.0 headers. We the extra subdirectory? Other than that everything looks 100% correct. We should get an sr= for the other-licenses change.
Attachment #234743 - Flags: review+ → review?(aaronleventhal)
(In reply to comment #9) > (From update of attachment 234743 [details] [diff] [review] ) > Ginn, my biggest concern is, don't we now need the dynamic ATK library check? It won't crash. What we need is just some enum and structure defination. The structure size doesn't change between ATK versions. > If we don't do that, it will either crash or just not work right, and > confuse the user. Can we do it in a separate bug? I don't think it's a simple fix. > Ginn, also do we need to have a separate atk-1.0 directory? I'd say put it > directly in other-licenses/atk, because we might eventually update to atk-2.0 > headers. We the extra subdirectory? I want to keep consistent with /usr/include/atk-1.0/atk Developer used to include <atk/atk.h> So we don't need change the code for switching.
Attachment #234744 - Flags: review?(aaronleventhal) → review+
Benjamin, what other formal approval do we need to checkin the ATK 1.12.1 headers in other-licenses? We have the LGPL analysis from Frank Hecker via email.
Frank's approval is sufficient. You will of course need to write a patch to client.mk to checkout the new source directory (I can review that).
Created attachment 235061 [details] [diff] [review] patch for client.mk
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Whiteboard: [ready for checkin]
OK, so why do we have ATK 1.12.1 in a directory called atk-1.0?
(In reply to comment #14) > OK, so why do we have ATK 1.12.1 in a directory called atk-1.0? > To be consistent with /usr/include/atk-1.0/atk The library's binary file is also named libatk-1.0.so.
You need to log in before you can comment on or make changes to this bug.