Bug 469347

Summary: Refactor the bridge
Product: [Mono] UI Automation Reporter: Andres Aragoneses <aaragoneses>
Component: Winforms - ATKAssignee: E-mail List <mono-a11y-bugs>
Status: NEW --- QA Contact: E-mail List <mono-a11y-qa>
Severity: Enhancement    
Priority: P4 - Low    
Version: Unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Andres Aragoneses 2009-01-26 15:24:49 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>
Comment 1 Brad Taylor 2009-01-26 15:33:22 UTC 
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.
Comment 2 Andres Aragoneses 2009-01-26 15:38:56 UTC 
(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.