Bugzilla – Bug 469347
Refactor the bridge
Last modified: 2009-10-28 20:09:42 UTC
Interesting things to overcome: - Abstract methods are not always necessary and are usually left empty with /*TODO*/ marks (for example the ones in ParentAdapter). - Fix this FIXME in Adapter.cs which means a lot of refactoring: "consider to add a new param here: Adapter parent; in order to have the parent always accessible, and prevent workarounds such as using provider navigation (like in the UiaAtkBridge.Window or UiaAtkBridge.ComboBox cases). - Remove all warnings. - Split files which have more than one class, in n files, for instance List.cs. - In cases where there are more than one class in a file, maybe it's better to think yet again if it's better to split them or keep them in one (for example, see the FIXME in AutomationBridge::HandleNewStatusBarControlType). - Fix the FIXME in IncludeNewAdapter: "FIXME: figure out why we can't uncomment this:" - Be more specific in some constructors (for instance fix the FIXME in ComponentParentAdapter one). - Remove the GLibHacks class. - Prepare the bridge to be prepared for interface changes at runtime (MenuItem elements that suddendly have sub-menuitems; comboboxes that change style, etc.). - <put your wishlist item here>
Additionally, it seems critical to me to handle Name and NameProperty changes at a higher level (Adapter...?). This should be a simple fix and a big win for us as we won't have to deal with listening to AutomationPropertyChanged events for NameProperty on every single control.
(In reply to comment #1) > Additionally, it seems critical to me to handle Name and NameProperty changes > at a higher level (Adapter...?). This should be a simple fix and a big win for > us as we won't have to deal with listening to AutomationPropertyChanged events > for NameProperty on every single control. Sounds good.