[atk]Build properly when libatk < 1.12.1 on build platform

RESOLVED FIXED

Status

()

RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: ginnchen+exoracle, Assigned: ginnchen+exoracle)

Tracking

({access})

Trunk
All
Linux
access
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 2 obsolete attachments)

(Assignee)

Description

13 years ago
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.
(Assignee)

Comment 1

13 years ago
Created attachment 232872 [details] [diff] [review]
patch

Also clean up unused variables, typedefs.
Assignee: nobody → ginn.chen
Status: NEW → ASSIGNED
Attachment #232872 - Flags: review?(aaronleventhal)

Comment 2

13 years ago
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?
(Assignee)

Comment 3

13 years ago
I have the same question.
I'm wondering what's the proper way to let user know.

Comment 4

13 years ago
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 5

13 years ago
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.
Attachment #232872 - Flags: review?(aaronleventhal)
(Assignee)

Comment 6

13 years ago
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?

Updated

13 years ago
Summary: [atk]Do not initialize a11y module if libatk < 1.12.1 → [atk]Build properly when libatk < 1.12.1 on build platform
(Assignee)

Comment 7

13 years ago
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?
(Assignee)

Updated

13 years ago
Attachment #234743 - Flags: review? → review?(aaronleventhal)
(Assignee)

Comment 8

13 years ago
Created attachment 234744 [details] [diff] [review]
ATK 1.12.1 headers
Attachment #234744 - Flags: review?(aaronleventhal)

Updated

13 years ago
Attachment #234743 - Flags: review?(aaronleventhal) → review+

Comment 9

13 years ago
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)
(Assignee)

Comment 10

13 years ago
(In reply to comment #9)
> (From update of attachment 234743 [details] [diff] [review] [edit])
> 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.

Updated

13 years ago
Attachment #234743 - Flags: review?(aaronleventhal) → review+

Updated

13 years ago
Attachment #234744 - Flags: review?(aaronleventhal) → review+

Comment 11

13 years ago
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.

Comment 12

13 years ago
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).
(Assignee)

Comment 13

13 years ago
Created attachment 235061 [details] [diff] [review]
patch for client.mk
Attachment #232872 - Attachment is obsolete: true
Attachment #234192 - Attachment is obsolete: true
Attachment #235061 - Flags: review?(benjamin)

Updated

13 years ago
Attachment #235061 - Flags: review?(benjamin) → review+

Updated

13 years ago
Whiteboard: [ready for checkin]
(Assignee)

Updated

13 years ago
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?
(Assignee)

Comment 15

13 years ago
(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.