[PyKDE] Providing DCOP methods
jbublitz at nwinternet.com
Fri Feb 18 04:30:01 GMT 2005
On Thursday 17 February 2005 19:39, Paul Giannaros wrote:
> 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
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).
More information about the PyQt