Monday, April 7, 2008

Moving, UIA Progress


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:

Screenshot of a winforms app showing up in Accerciser!
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:

Diagram of dependencies in UIA-related 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.


Christoph Langner said...

Hi! Sorry for my question, but i really like yout gtk theme. Which theme is that? Thanks, Christoph.

Sandy said...

Darkilouche, by the remarkable Jakub Steiner and Garrett LeSage.

I find it easier on the eyes sometimes.

Mario Carrion said...

You are doing an excellent job and using the diagram is great, it always helps me to understand the state of the project.

In some weeks will be joining you for working together, see you soon.

Sandy said...

@mario: I'm glad it helps. Sometimes I wonder if my blogs are a little much considering where I'm syndicated, but I think it's a good way to document the design process, etc.

Looking forward to working with you@

lancewf said...

Sorry to hear that you are leaving. We should get together sometime before you go. Maybe go out to eat for another go bye lunch or dinner. I know two was not enough from last time.


Sandy said...

Lance! That would be sweet, we should do that. I'm out of town this weekend but maybe after that.