Re: Scripting in Gnome

Let's go back to an eariler part of the thread (I'm suffering serious email lag ATM). I said:

We have this already, via the python bindings for at-spi.  ...

We just need some folks to start writing the scripts and clients, the tools are there.  It's just that nobody is taking advantage of this capability yet, outside of GOK and gnopernicus.
This sounds excellent, and something that I could really use.  Why isn't
this advertised more?

I think people think of it as 'that accessibility stuff' and don't stop to think of it as a general service.

Chris Parker

And Sean wrote:

Given my weak understanding of this, I'm seeing a lot of shortcomings:

- can only access what's in the UI, which may not reflect the full
range of features available or necessary

Not strictly true - and I was speaking of applications, in which case if the feature isn't in the UI, it doesn't exist :-P
(but see below)

- may be subject to UI changes, meaning that the script interface's
API/ABI is now bound to the UI

Depends on how you write the script, but true to some extent.

- querying information could be very difficult (assuming that info is
even *in* the UI), as the script may have to check around dozens of
widgets to assemble the information it needs.

What information of interest to the user is not in the UI? I really do not get your use case here.

- interferes with user interaction (has to open the preferences window
to check a setting, for example, interrupting and confuzzling the user)

Not always true either - you can interact with lots of application objects in a running app without posting them, as it turns out. But why would you open a preferences dialog to check a setting that was available in gconf, for instance? Again, without use cases this discussion doesn't have much clarity.

In short, unless I have a gross misunderstanding of the at-spi framework
(yes, likely) it does not at all implement a system that is truly usable
for production scripting of a user desktop in a transparent manner. (that sounded way too much like marketing speak...)
It depends on what you are trying to accomplish. This whole topic of 'scripting' is so broad and fuzzy that people seem to be talking past each other about it all the time. What I was responding to was a more UI/Application/control type of scripting, i.e. COM-ish, where the scripts are dependant on applications and their GUIs being loaded in order to do their jobs.

If you're trying to write applications and tools (via a scripting language, perhaps) that don't interact with the desktop UI, at-spi might not make that much sense. But I don't think that's 'scripting' except in the sense that you may use a "scripting language" - certainly you can tweak gconf keys or make calls to any GNOME library from python. So if what you need to do can be done via python bindings to core Gnome libraries, of course at-spi is irrelevant.

So, what do _you_ mean by 'production scripting of a user desktop in a transparent manner' ?

at-spi is a powerful mechanism for extending and interoperating with running applications via scripts (among other things, of course). And scripting languages such as python can be used to interact with most of the Gnome core libraries. IMO the (transparent) interaction with running applications, without intimate knowledge of their internal data structures and objects, is by far the harder problem, and one where at-spi has a lot to offer. If what you want is some way to write a 'print utility' for Gnome that prints a document from, say, gimp without user interaction, it's tricky:

* the application must be modular enough that it can be invoked without its GUI and print documents - in general not true unless the application was designed with that capability in mind AND you need appropriate bindings (bonobo or python);


* you need a way to run the application and invoke the appropriate UI commands from a script.

at-spi gives you the second - in fact it would be fairly trivial to write a script that looked up an application from the Gnome mimetypes registry, launched it, opened a specific file, and invoked the 'Print' followed by 'Quit' from the menus. Granted, this would cause application windows to be opened, etc. but it would not require any changes to the application itself and would rely only on the use of standard menu items (ensured by HIG compliance). You could even do this in a virtual display if you wished. Having Gnome applications provide standard UI actions via BonoboControl or b-a-s would be nicer, of course, but this would require coordination and consensus that this was worth doing, whereas at-spi allows leverage of existing application capabilities. If you need scripting access to non-GUI components or to libraries, language bindings such as Python bindings for the library make more sense IMO, but they require that the libraries are functional stand-alone. This is not true of most applications' codebases.




- Bill
desktop-devel-list mailing list
desktop-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]