[PyKDE] Enterprise Desktop - Scripting

[Kaleb Pederson]

On Tuesday 16 December 2003 12:21 am, Jim Bublitz wrote:
> 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.

As this has been an annoyance of mine for a couple of years, I would 
definitely have to agree.  I was hoping that as QSA became more stable we 
would start to see pervasive scripting capabilities.  An example, although 
non-kde, would be the ability in gimp to make a selection, then record the 
different steps that you wanted applied to any selection.  Similarly, in 
KSpread, the ability to select a bunch of cells, and then record a bunch of 
actions.  These, although extremely simple, would help a lot for many 
different situations that I run into frequently - and I doubt that I'm alone 
in this area.

I haven't done any kde programming (strictly qt so far), so I can't say 
whether or not DCOP is going to be easily scriptable or not, but I would 
think that we could use the command design pattern to grab actions.  If 
everything were done using signals, we could have a manager of a sort that 
keeps a history of all the actions and "records" them or something of that 
sort.  This is quite simplistic, but recording and playing back would be a 
large improvement over nothing.  Obviously, we would still want to make part 
of the API public and allow the users to make their own choice to support 
strong scriptability.

> 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]

There are many choices here.  I would love to see support for Python as the 
KDE scripting language as it is powerful and could well represent the current 
structure of the KDE project (aside from multiple inheritance of Qt based 
classes, which probably isn't extensively used?), but I'm probably biased as 
I have done quite a bit of PyQt development.  We could use QSA, or something 
similar, but I'm currently in no position to comment on its pros or cons.  We 
could create our own language (why)?

> 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 think KDE definitely needs to pay attention to scriptability in the future, 
and this already may be slated as I haven't yet checked.  Whatever the future 
holds, I would hope that it is a language much more capable than VB up to 
version 6 anyway.

So where do you, the kde developers, place scriptability?  What would you like 
to see happen?  What will it take to make it happen?

Thanks for your comments and suggestions.

--Kaleb

> 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
> ... [e-mail address removed]
>
> [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.
> _______________________________________________
> PyKDE mailing list    PyKDE at mats.imk.fraunhofer.de
> http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20031217/f2ffb957/attachment.bin