Re: Scripting in Gnome

[Bill Haneman <Bill Haneman Sun COM>]

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);

OR

* 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.

regards,

Bill

> > regards,
> >
> > - Bill
> > _______________________________________________
> > desktop-devel-list mailing list
> > desktop-devel-list gnome org
> > http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >