[PyKDE] Providing DCOP methods

[Jim Bublitz]

On Thursday 17 February 2005 19:39, Paul Giannaros wrote:
> Hey
> I've been looking for information on connecting to DCOP and providing
>  methods accessible over DCOP.
> I take it from what i've read in the mailing list archives and from what
>  docs I could find on the subject such functionality is not available in
>  pyKDE? More specifically, is there a way to do it given what pyKDE gives
>  you? No having to resort to writing a C++ wrapper around the DCOPObject
>  class, etc..

> You can do this kind of thing via dcoppython but for it to work it
>  creates its own KApplication. I was thinking about trying to use that
>  KApplication it creates (as you cannot have two QApplication instances)
>  and re-using it for the rest of my application but unfortunately the
>  KApplication object it creates is not accessible via pcop.so in any way.

PyKDE has supported DCOP for about a year. The details are in 
doc/dcopext.html. If you don't have the docs you can find them in the tarball 
at http://www.river-bank.demon.co.uk/download/snapshots/PyKDE/.

The DCOP stuff is based on the dcoppython code by Torben Weis and Julian 
Rockey, but integrated into PyKDE. It requires dcopext.py and dcopexport.py 
which are in the extensions/ directory in the tarball, but a normal install 
will have already placed those modules in /site-packages, so you can just 
import them by name. No C++ is required for supported data/object types 
(which are nearly all of the commonly used types - see docs).

There are also two simple examples (example_dcopexport.py and 
example_dcopext.py) in the PyKDE examples/directory.

> Python KOffice module maintainer, KTTSD developer

What is Python KOffice?

At one time I had a plugin interface for KSpread that allowed creating 
"built-in" functions or scripting KSpread (something like v1.2) from Python. 
Are you taking an approach like that or working via DCOP?

PyKDE doesn't support KOffice specific types (types defined in KOffice instead 
of basic C types or Qt or kdelibs defined types). It might be possible to do 
that, or might be easier just to create a simple KOffice wrapper, do bindings 
for that and script directly from Python.  

I haven't really looked at doing the DCOP stuff, but if it requires KOffice 
defined types, it would probably require bindings for KOffice, which isn't 
likely to be a good idea. There might be some way around this (or there might 
not). If it doesn't require KOffice-specific types, it's a lot more limited 
than a simple wrapper/bindings would be.

A simple wrapper with Python bindings is much easier to do and allows access 
to more functionality (pretty much the entire API, or as much as you'd want 
to expose) than DCOP would allow. In some tests with KSpread it was hard to 
tell if the wrapper/bindings was faster than KSpread itself or not (for 
example, populating a large number of cells).

Jim