[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