Created attachment 91378 [details] [review]
Something to think about

This patch basically allows a script to be applied to a given event not just by the event's top level application, but by it's parent document accessible's URL.
There is a sample GMail script included that gets loaded when gmail is loaded in the browser, and gets unloaded when gmail leaves. It also sets the active script to be either the document or application script of the focused accessible.

For some reason now there is a separate code path for toolkit scripts, but I would think it would make sense to make a formalized search order of URL->application->toolkit. Also, a formalized reverse inheritance setup, meaning that a Pidgin script would have the following inheritance: default->GAIL->pidgin. A gmail script will have the following inheritance: default->Gecko->Mozilla->gmail. The lineage is similar today, I would just do some changes, like putting all the scripts besides the default one in the scripts package, create GAIL and OO.o toolkit scripts (they could just be dummies for now), and write clean search order code in focus_tracking_presenter.py.

I think the tricky question is: A web app will not necessarily run in Mozilla, or in Gecko for that matter. Maybe a special web app superclass could be created later that would do some amazing python-foo, and change the inheritance at runtime (but before object initialization).

> For some reason now there is a separate code path for toolkit scripts

Here's the logic that's in focus_tracking_presenter.py:_createScript:

1) First see if there is a custom script for the application.  This is based upon application name (app.name).   The custom script for the application can freely subclass any script it wants to subclass, but it typically just subclasses default.Script.  The scripts for applications live in 'orca/scripts'.

2) Failing the presence of a custom script for the application, see if there is a custom script for the toolkit.  This is based upon the toolkit name (app.toolkitName).  As with application scripts, the custom script for the toolkit can freely subclass any script it wants to.  The scripts for toolkits live in 'orca' as a means to help avoid namespace conflicts with application scripts (e.g., an app and a toolkit with the same name).

3) Failing the presence of a custom script for the toolkit, use default.Script.

At the time all this logic was done, there was an assumption that GAIL was the de facto implementation of the AT-SPI and all other toolkits (e.g., Gecko, Java, OOo, etc.) would behave like GAIL.  Thus, we didn't name default.py GAIL.py, we just named it default.py.  For the most part, this assumption has worked out OK, but some implementors of the AT-SPI do indeed like taking liberties in their interpretation of the specification

Hope this helps,

Will

(In reply to comment #2)
> Here's the logic that's in focus_tracking_presenter.py:_createScript:
> 
I got familiar with the logic while writing the patch above. It just seems like the routine could be so much simpler and prettier if the scripts are treated as tiers with an ascending order of precedence. Especially since we are adding another type of scripts, for web apps.

Here is example pseudo-code, just an idea of how simple it could be:

sys.path.insert(ORCA_SCRIPTS, 0)
sys.path.insert(USER_SCRIPTS, 0)

moduleName = None
for identifier in (doc_url, app_name, tk_name):
  moduleName = getScriptName(identifier)
  if moduleName: break

script = None
if moduleName is not None:
  try:
    module = __import__((moduleName, globals(), locals(), [''])
    script = module.Script()
  except:
    pass

if not script:
  script = default.Script()

sys.path.pop(0)
sys.path.pop(0)

> 1) First see if there is a custom script for the application.  This is based
> upon application name (app.name).   The custom script for the application can
> freely subclass any script it wants to subclass, but it typically just
> subclasses default.Script.  The scripts for applications live in
> 'orca/scripts'.

My thoughts are that an application script should subclass the toolkit of the application. This is pretty much the case today.

> The scripts for toolkits
> live in 'orca' as a means to help avoid namespace conflicts with application
> scripts (e.g., an app and a toolkit with the same name).

Has this been an issue? this hinders the capability of 3rd party script writers to write toolkit scripts. It seems to me the the price we pay for this is high.

> At the time all this logic was done, there was an assumption that GAIL was the
> de facto implementation of the AT-SPI and all other toolkits (e.g., Gecko,
> Java, OOo, etc.) would behave like GAIL.

I agree that most of this is still valid. I think that default.Script should be compliant with AT-SPI spec. GAIL.Script that derives from it should pretty much be empty, but in the future when we discover quirks in GAIL we could put workarounds in GAIL.Script for specific GAIL versions without affecting the other toolkit scripts.

Created attachment 91654 [details]
Diagram of present, and proposed design.

I am hoping that this could somehow be rendered accessible. It's a UML diagram.
I'm following this with a PNG for easier viewing.

Created attachment 91655 [details]
Diagram of present, and proposed design (png).

This is a PNG version of the above diagram.

Eitan and I talked about this at GUADEC and have decided to postpone this work until other higher priority refactoring is done.  We're still also not sure if this refactor is actually one that will work well outside the laboratory.  :-(

Created attachment 109280 [details] [review]
Begining something

This script management style allows scripts to determine if they are relevant or not. And we don't necessarily have to depend on the packages name, or on the mappings in the settings file.

Combined with the idea of patch 91378 we could have per-URL scripts!

See also http://mindforks.blogspot.com/2008/03/uniquely-identifying-chunks-of-ui.html for related work.

If you have any questions at all regarding aria templateid now is the time to ask them! The PFWG is discussing the inclusion of this property in the specification. Right now there are not many people pushing to keep it.