Moving, UIA Progress

Moving

Looks like we'll be moving from San Diego to Las Vegas some time around May 1st. We're having some trouble finding a decent home to rent, but I'm hoping that will all resolve itself in the next few days.

UIA Progress

Last week, Andres committed a ton of fixes to get stuff working in the UIA<->ATK bridge. I spent a few days working on my end (winforms and providers), until we finally got this:


So that was exciting. Our friends on the Mono team helped us figure out that some of our problems were caused by the fact that Winforms actually has a current dependency on GTK+ to get theme colors! The initialization of GTK+ before we load our UIA<->ATK bridge was causing runtime failures. We have filed a bug on it, and will probably be removing the GTK+ dependency in Winforms (see bug for details). Currently we work around it in our patch to Winforms.

Of course, the implementation to achieve this wasn't really too great. My providers were depending directly on Andres' bridge. So now it's time to start working more on the "core". I'm experimenting with it now. Here's an updated version of my old diagram, color-coded to differentiate between MS assemblies and our new assemblies:


Notice that I have removed the core, and in its place is the MS-defined UIAutomationProvider assembly. I played around with different designs, but there is a fundamental problem in that MS intends all interop between providers and *their* core to happen via a static class called AutomationInteropProvider, that lives in the UIAutomationProvider assembly along with a ton of useful interfaces. Well, we can't add new public interfaces to that assembly, but when messages come to the AutomationInteropProvider they need to somehow get to the bridge. And I'm trying to avoid excessive reflection.

So right now I'm assuming that I can define a good bridge interface in a new assembly, UIAutomationBridge, that only depends on MS's UIAutomationTypes assembly. A class in the UIA<->ATK bridge assembly implements that interface, and the AutomationInteropProvider uses reflection only once in order to find that class. This prevents me from using interfaces in the UIAutomationProvider assembly in the bridge interface, but I think this will be okay...we'll just have to pass a few things around as plain old objects, and document what the client can expect from them.

I'm thinking that this AutomationInteropProvider class is already designed to represent the "core", so I'm just going to run with that idea this week and see where it takes me. It's all happening in the olive and uia2atk projects.

My winforms providers are a little nicer now, but they're not much use until the bridge grows a little bit. So this week I'll focus a lot on these design issues, and also I need to write unit tests against MS's implementation to derive a bunch of constant values.

It should be a fun week; I like this sort of stuff.