2008년 1월 13일 일요일

CLR Add-In

Today I came across CLR Add-In. You can start reading from "System.AddIn Resources" link on the left sidebar.

Its discovery and adaptation model looks rather comparable to those of zope.interface, but it also deals with isolation. Reading the blog, it's interesting to see what design choices there are, and how and why CLR Add-In Team made those decisions.

2008년 1월 11일 금요일

Using AT-SPI from IronPython (2)

Before continuing, let me mention that all the relevant code is in the FePy repository:
https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/atspi/

Now IIOP.NET is built, it's time to compile IDL. IDL stands for "Interface Description Language", and it is used to (surprise) describe the interface. AT-SPI's CORBA interface is described in /usr/share/idl/at-spi-1.0/Accessibility.idl, and it includes a bunch of other files. Some of these files are in different directories, so one needs to specify them.

The compiler built is under IDLToCLSCompiler/IDLCompiler/bin. Copy these files (IIOPChannel.dll, IDLPreprocessor.dll, IDLToCLSCompiler.exe) to the current directory, and run:

$ mono IDLToClsCompiler.exe \
-idir /usr/share/idl/bonobo-2.0 \
-idir /usr/share/idl/bonobo-activation-2.0 \
Accessibility /usr/share/idl/at-spi-1.0/Accessibility.idl


This should produce Accessibility.dll in the same directory. build.sh in the repository automates the process up to this point (download, build, and IDL compilation).

So how does one connect to the server? This is "a well known problem" that has its own FAQ entry. Basically, one obtains IOR, "Interoperable Object Reference", by out-of-band mean, as one gets URL from the bookmark. After one got the first object reference, one can follow links to other objects.

It turns out that AT-SPI publishes IOR as a property of X root window under the name "AT_SPI_IOR". Now one could go read X protocol specification and manually construct GetProperty request (opcode 20), etc., but there is an easier way. xprop utility can display X properties, so one runs "xprop -root AT_SPI_IOR" and parses the output. xprop.py in the repository implements this.

Now IOR is a long sequence of hexademical digits, and one needs a tool to decode it. ior-decode-2 in orbit2 package can do so. If you decode IOR from xprop, you can notice a problem. AT-SPI (actually CORBA implementation it is using, namely ORBit2) uses Unix domain socket by default, but IIOP.NET can't use it. One solution is in the ORBit2 FAQ I linked above. Create .orbitrc with this line.

ORBIIOPIPv4=1


This post is already quite long, so let's quickly skim the rest. corba.py implements the necessary initializations from IIOP.NET documentation. typed.py is a workaround for IronPython's limitation (namely the lack of cast operator), first suggested by Dino Viehland. And this is the meat of cliatspi.py.

orb = corba.init()
ior = xprop.get('AT_SPI_IOR')
obj = orb.string_to_object(ior)
registry = typed.typedproxy(obj, Accessibility.Registry)


tree.py is an example AT-SPI client I wrote, printing a tree of accessible objects in the current desktop. It imports cliatspi on IronPython, but imports an existing AT-SPI binding on CPython. (I used one in Debian python-at-spi package.) As IDL is language-neutral, this script actually runs identically on both CPython and IronPython. Extending tree.py to be a useful tool like UISpy on Windows is left as an exercise to the readers.

2008년 1월 10일 목요일

Using AT-SPI from IronPython (1)

This adventure started when Jim Hugunin mentioned System.Windows.Automation library new in .NET 3.0.

GUI test automation and assistive technology (such as screen readers) share some common needs. While UI Automation is named after the former, AT-SPI is named after the later. AT-SPI, which stands for "Assistive Technology Service Provider Interface" -- this is the first of lengthy acronyms that will appear in this post -- is an accessibility standard for Unix/X world. Initially developed by the GNOME project, now it is also supported by Java, Mozilla, OpenOffice.org, and Qt 4.

While Microsoft-Novell interoperability agreement announced an intention to implement UI Automation on Linux (see above Wikipedia links for details), that's not available today on my Debian GNU/Linux desktop. So I looked for a way to use AT-SPI from IronPython on Mono.

First thing I did was to install at-spi package from the Debian repository. That was obvious... Less obvious was how to use it after installation, especially because I am not using GNOME desktop (I am an IceWM user). After some search, I added following two lines to my .xsession.

export GTK_MODULES=gail:atk-bridge
/usr/lib/at-spi/at-spi-registryd &


Now AT-SPI has an accessibility broker which clients talk to, and it talks CORBA. CORBA, which stands for (I warned you) "Common Object Request Broker Architecture", is like a big brother of IPC mechanisms. CORBA has been around for a long time, and while it is sometimes accused of bloat, its bloat is nothing compared to certain XML-based "Simple" Object Access Protocol.

So how does one use CORBA from Mono? A little search found a nice project named IIOP.NET, which "allows a seamless interoperation between .NET, CORBA and J2EE distributed objects." Cool. This project even has a support table for Mono on its status page! The download page mentions both binary and source release, but I couldn't find the binary release. No problem. Download the source release, unzip, and run "make -f Makefile.mono". Note that Makefile is for nmake, a Microsoft dialect of make, which is not compatible with GNU make. The build finished with no problem.

Bah, this is getting too long. Let's continue on the next post.