[PyKDE] Re: dcop

[Jim Bublitz]

Jim Bublitz <jbublitz at nwinternet.com> writes:
>> The way I have it setup now is:

> 'now' meaning 'in CVS' ?

Meaning on my computer :( I can send you a tarball if you'd like to test it 
out and comment on it. It's pretty easy to install - don't even have to 
rebuild all of PyKDE (just kdecore).

>> dcop_add needs a type specifier for numeric types,

[...]

> of course. Is it valid, to add a type specifier for other types (like
> QString)? This would simplify automated code ...

Good point. What I do right now is ('rtype' is a string defining the return 
type, 'value' is the actual value to be marshalled, 's' is the QDataStream 
being used):

   from dcopext import numericTypes, stringTypes

   if rtype in numericTypes:
       dcop_add (s, value, rtype)
   elif rtype in stringTypes and isinstance (value, str):
        dcop_add (s, eval ("%s(%s)" % (rtype, value)))
   else:
        dcop_add (s, value)

The second clause allows using Python strings in place of QString/QCString. 
dcop_add is implemented in C++ as a bunch of overloaded methods (dcop_add 
(QDataStream, int, QCString = "int"), dcop_add (QDataStream, QPoint), etc).

I could add a default QCString to each method (like dcop_add (s, QPoint, 
QCString = "QPoint"); the "problem" is it will cause a bunch of "unused 
variable" warnings when compiling, because there isn't any reason to use the 
value. The entire method is just:

void dcop_add (QDataStream s, QPoint value)
{
    s  << value;
}

I'll have to think about it - I do like having a consistent set of methods 
rather than the two variations I have now, but I don't like the warnings.

>> I've also written a small module (based on pydcop from kde-bindings) so the
>> user rarely has to worry about packing or unpacking QByteArrays anyway:

[...]

> Ok, there goes my nice PyDCOP.DCOPClient class :-) What do you do
> about overloaded functions?

> This is very nice stuff. This will be in rc2 ? When can we expect rc2
> to be released ...

> I have implemented a DCOPServer class which works along the same
> lines to provide automatic marshalling for DCOPServers:

> class MyDCOPServer(PyDCOP.DCOPServer):

>   def __init__(self):
>        PyDCOP.DCOPServer.__init__(self,
>                                   name="myserver",
>                                   interface="MyDCOPServer",
>                                   methods=[
>                                       "int foo()",
>                                       "void foo(QString string)",
>                                       "QCStringList bar()" ])

>    def foo_(self):
>        return 1234

>    def foo_QString(self,s):
>        pass

>    def bar(self):
>        return [ "This","is","a","list" ]

> I support overloading by (optionally) appending the function signature
> to the function name:

>    foo() (no arguments) -> foo_
>    foo(QString)         -> foo_QString
>    foo(int,QString)     -> foo_int_QString

>    all of the above     -> foo

> you either:
> - implement foo and use default args or check the types
>   manually
> - implement foo_, foo_QString and foo_int_QString

> I found, using a precompiler for an interpreted language like python
> is not necessary.

I stole from pydcop too - basically the same thing, but __init__ just takes 
the "id" for the DCOPObject. I added an "addMethod" method:

    addMethod ("QString someMethod (int)", self.some_method)

where the first arg is the C++ signature and the second is the Python method 
that corresponds to it (is actually called). The Python method names don't 
have to correspond to the C++ names and could be any Python method - in the 
same class, different class or a global method. The supeclass 
(PyDCOP.DCOPServer in your case)  builds a Python dict from successive 
addMethod calls like:

    {"someMethod(int)": <method object>}

so the signature strings as indices take care of overloads. The method object 
has the signature already parsed into return type and argument type list. 
"functions()" is provided in the superclass too, and uses the dict to provide 
the responses to "remoteFunctions" call.

It's bascially the stuff from pcop.cpp, but in Python and using PyKDE.

If you want to play with the stuff I have so far (works, but not necessarily 
complete), send me your email address privately and I'll mail a tarball and 
installation instructions. I'd appreciate some feedback, as I'm not that 
familiar with using DCOP.

Jim