[Webkit-unassigned] [Bug 106216] [EFL][WK2] Expose accessibility hierarchy in WebKit2-EFL.
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Jan 15 02:36:10 PST 2013
https://bugs.webkit.org/show_bug.cgi?id=106216
--- Comment #18 from Gyuyoung Kim <gyuyoung.kim at samsung.com> 2013-01-15 02:37:56 PST ---
(In reply to comment #15)
> > I wonder why EFL port only needs to use HAVE(ACCESSIBILITY) together. EFL port also enabled HAVE(ACCESSIBILITY) guard as GTK port.
>
> Because we wanted to have a possibility of turning Accessibility on/off. This is a matter of having ATK library. In case ATK is not available, we can easily turning it off. See Source/cmake/OptionsEfl.cmake (line 50). Why PLATFORM(EFL) and HAVE(ACCESSIBILITY) go together?. Because PLATFORM(EFL) alone will not cover every occurrence of ATK callings.
I don't understand this well. OptionsEfl.cmake enables ENABLE_ACCESSIBILITY to find ATK package.
if (ENABLE_ACCESSIBILITY)
find_package(ATK REQUIRED)
else ()
add_definitions(-DHAVE_ACCESSIBILITY=0)
endif ()
Then, the HAVE_ACCESSIBILITY is enabled by Platform.h
#if !defined(HAVE_ACCESSIBILITY)
#if PLATFORM(IOS) || PLATFORM(MAC) || PLATFORM(WIN) || PLATFORM(GTK) || (PLATFORM(CHROMIUM) && !OS(ANDROID)) || PLATFORM(EFL)
#define HAVE_ACCESSIBILITY 1
#endif
#endif /* !defined(HAVE_ACCESSIBILITY) */
It means EFL port will enable HAVE_ACCESSIBILITY if we don't off ENABLE_ACCESSIBILITY in OptionsEfl.cmake. If we off ENABLE_ACCESSIBILITY in OptionsEFl.cmake, HAVE_ACCESSIBILITY is defined with disabled. So, it won't be enabled in Platform.h again. It seems to me that we already can control HAVE_ACCESSIBILITY by OptionsEfl.cmake definition. If I miss something, please let me know.
--
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