[PyKDE] Enterprise Desktop - Scripting

Jim Bublitz jbublitz at nwinternet.com
Tue Dec 16 09:58:00 GMT 2003


One of the features of the "standard" enterprise desktop that 
appears to be missing from all of the proposals I've seen is 
scriptability. It makes little difference what enterprise 
desktop environment you're comparing to - Lotus 1-2-3 and 
Borland's Quattro Pro for DOS were scriptable, and of course 
Visual Basic is pervasive in the Windows environment.

If KDE lacks in any area, it is the area of scriptability. A few 
KDE apps (Scribus) are Python scriptable; KDE-bindings doesn't 
even cover much of KDE yet (as far as I know); DCOP and/or QSA 
or JavaScript are not "user-friendly" scripting in my opinion.

OpenOffice is Python scriptable and probably more Gnome than KDE 
apps (gnumeric, gnucash) are scriptable (although gnucash seems 
to use only scheme - not exactly as friendly as VB either). 
Python bindings exist for GTK and wxWindows, and are probably 
more popular because they're more easily cross-platform (Qt is 
expensive to use on Windows).

The benefit of scriptability is that it allows users to extend 
and automate applications - similar in many ways to redirection 
and piping on the Unix command line, but also allowing things 
like dialog boxes, data validation, transfer and conversion - in 
short creating custom spreadsheets, mail clients, WP documents, 
or whatever using existing APIs but without having to write C++ 
code or modify the application itself.

My personal bias on this subject stems from the fact that I 
maintain/develop PyKDE (based on Phil Thompson's sip and PyQt). 
PyKDE can already handle (in Python) virtually everything that 
kdelibs can do, including panel applets, KParts, IOSlaves, 
Control Center modules, and DCOP. Some of those still have some 
rough edges, but the basics are there. Similar techniques can be 
used to make KOffice and Kontact scriptable [1] 

In the past I've had Python scripting working for KSpread, for 
example, and could create "built-in" formulas in Python, as well 
as use Python to set-up, format and manipulate spreadsheets, and 
to do things KSpread can't presently do (load and operate on 
spreadsheets in the background, for example). Execution speed is 
not an issue, as bindings run largely in the C++-space anyway.

There are also tools in development to make the generation of 
Python bindings simpler, including more documentation for the 
process of developing bindings.

The major limiting factior in any of the above for PyKDE or 
similar approaches is time - there are only a few people working 
on this and a lot of work to do (although again, the basic 
"technology" isn't too difficult). Please also note that this is 
not an "invasive" add-on - it requires no changes to KDE to 
implement, doesn't force linking to any special libs, etc. (A 
few changes might make life a little easier, but it's not a big 
deal).

Personally, I'd find Python to be the optimum alternative to 
something like Visual Basic Realistically, Perl is more widely 
used (although not as "newbie-friendly" or object oriented), and 
other languages like Ruby, TCL, etc. have their adherents. 
Regardless of which language or languages are supported, 
scripting is something I feel KDE needs to pay more attention 
to.

I'm not sure what support to scriptability KDE can offer - at the 
very least it would be nice to see some recognition of the need 
for scripting and some emphasis on making it happen. I'd be 
happy to discuss this further with anyone interested.

Jim Bublitz
jbublitz at nwinternet.com

[1] The approach I'd favor is writing a "thin" C++ wrapper and 
writing Python bindings against the wrapper - the resulting 
bindings can be more user-friendly than the underlying API. 
Implementation is as a plug-in, but with access to the entire 
API.




More information about the PyQt mailing list