[Webkit-unassigned] [Bug 76783] New: [GTK] Refactor GTK's accessibilitity code to be modular

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=76783

           Summary: [GTK] Refactor GTK's accessibilitity code to be
                    modular
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Keywords: Gtk
          Severity: Normal
          Priority: P2
         Component: Accessibility
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: msanchez at igalia.com
                CC: xan.lopez at gmail.com, mrobinson at webkit.org


So far, the AccessibilityObject wrapper for ATK has been mainly implemented in terms of the following few files, inside WebCore/accessibility/gtk:

  - AccessibilityObjectWrapperAtk.cpp: 2780 lines
  - AccessibilityObjectWrapperAtk.h: 67 lines
  - WebKitAccessibleHyperlink.cpp: 408 lines
  - WebKitAccessibleHyperlink.h: 63 lines

As you can see, there's a BIG file which basically implements both all the functions for an AtkObject wrapping WebCore's AccessibilityObject *and* also all the ATK interfaces supported at the time by WebKitGTK+, which makes that file huge.

Then we have WebKitAccessibleHyperlink.[h|cpp] in separate files because it represents another kind of GObject (it's a subclass of AtkHyperlink, which is *not* and AtkObject), which has been created separately not to mix more things inside of that AccessibilityObjectWrapperAtk.cpp file.

The obvious problem with that huge file is that its destiny seems to be to keep growing out of control as long as we add more code, implement more interfaces, fix bugs... which doesn't look like a good idea from the point of view of readability and also because of more practical issues (not to mix so many unrelated things in the same file).

So, the proposal behind this bug is to take all the implementations for the different ATK interfaces out of that file (similarly to what Mozilla does), so we can keep all the related code, includes, internal functions... properly organized in different files. This way, we would leave in the wrapper's file just the implementation of AtkObject's functions and the code to decide which interfaces would implement each (dynamically generated) subclass of WebKitAccessible, and nothing else.

Also, bonus points for this approach is that it would give us a good opportunity to make all that code (2780) compliant with WebKit's coding style rules once and for all, which is a nice plus if you ask me :-)

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