PyQt and DCOP Documentation

[Jim Bublitz]

Eric Williams wrote:

> Eric Williams wrote:
> 
>> I'm actually just trying to get the volume level out of noatun
>> in a python script, if anyone can help me with an example.
>> What, exactly, does one DO with a QByteArray in python?
>> 
> 
> Ok, figured out a workaround for that call; in case anyone
> else's having a similar problem:
> ----------------------------------------------
>         def getvol(self):
>                 res = self.rc.call("volume()")
>                 if res.isValid():
>                         return ord(res.data.data()[-1])
>                 else:
>                         return None
> 
> -----------------------------------------------

You should have 'kdcop' on your system. If you run it and scroll
down to 'noatun', you'll find that "volume()" returns an int -
hence 4 bytes on a 32 bit system (as a QByteArray). Looking at
res.type will also tell you that. It appears from adjustring the
volume control on noatun, that it varies from 0 -> 100 (')' =
48)

The type of 'res' is actually a DCOPReply instance - DCOPReply is
a class in Python and has 'data' and 'type' data members. 'data'
is a QByteArray instance, and 'type' is a Py string.
 
> Where rc is a DCOPRef object hooked to noatun.
> 
> For whatever reason, res.data.data() returns a 4-byte array, so
> here you
> take the last byte.  Am I doing that correctly, or is there a
> better way?
> 
> On to the next problem:
> -----------------------------------------------
>        def volup(self):
>                 curvol = int(self.getvol())
>                 newvol = curvol + 5
>                 res = self.rc.call("setVolume(%d)" % newvol)
>                 print "Setvol: ", res.isValid()
> 
> -----------------------------------------------
> I've tried various mutations of this.  This doesn't work at
> all. Anybody know how to do this?

The following will work for setting the volume:

self.call ("noatun", "Noatun", "setVolume(int)",
           "\0\0\0\50", "x", "x")

Works for me. (See (4) below)

OK - there are a whole bunch of issues here beyond the fact that
the PyKDE dcop implementation is somewhat broken:

1. You should get the KDE class ref docs if you don't have them
already. They have a good section on dcop. The docs at this
link:

ftp://ftp.kde.com/pub/devel/kdeapidocs/kdeapidoc-cvs.tar.bz2

can be linked to the PyKDE docs using the doc browser in
PyKDE-3.8.0. You can also browse from http://www.kde.org and
find online class ref docs ( in the "Developers" section).

2. PyKDE's dcop has never been tested. It exists primarily so the
kdecore module will build. I have pointed this out on the PyKDE
list, and no one has ever shown any interest. Yeah it'd be nice
if all of this stuff worked, but I'm one person doing 3 or 4
releases a year. 

3. PyQt and PyKDE docs - mobody writes them beyond the bare
minimum (methods that take different args than in C++, or aren't
implemented, etc). PyKDE has 600 classes and 10,000 methods. I'm
not writing that many docs - sorry. The C++ docs aren't *that*
hard for non-C++ programmers to read. Ignore the '&s' and think
of '->' == "." and for anything that looks like a template (<>
in the declaration) look at the PyKDE docs and see what I
substituted for that (if anything). Contributions are always
welcome. The PyKDE list handles questions promptly.

4. The two 'x's above are necessary because they actually hold
the return data and return data type (they're return values).
This method should return a Python tuple with those values - it
doesn't (see 2). Now that I have some concept of how this is
supposed to work, I'll implement that.

If you leave the "x"x out, PyKDE/sip won't be able to parse the
args for the call - it expects to see values there, but never
uses them.

There isn't any way to determine those are return values by
looking at the method signature, and the code for this is all
machine generated. The computer did it :) QCStrings are also a
special case - I don't believe they're really objects in Python
- they're strings and strings aren't mutable. It's fairly simple
to convert them to return values "internally* in PyKDE, but it
requires a little handwritten code.

5. There are actually a large number of dcopRef.call methods,
varying only by how many parameters they marshall. The only
version implemented is the one that takes no parameters. I'll
look at whether those are worth implementing - probably are, but
they also probably won't work the way the C++ version works. It
actually looks pretty messy to implement, because the args are
template types.

6. It would be nice if there were easy conversions - for example,
the volume() method call actually returned an int instead of a
QByteArray - or there was at least a built-in QByteArray->type
convertor. I'll also look at that and see if it's worth doing
something about. Otherwise I'll just document it.

None of this wonderful stuff will happen until the next PyKDE
release. KDE 3.2 is due Dec 8 (if on schedule). PyKDE for KDE
3.2 will follow by probably 2 weeks to a month (he said
optimistically) - the changes will be backported to all 3.1.x
versions though (none of this appears to exist in 3.0, but I
haven't really checked it out yet). The next release will build
against KDE 3.x.y where 0 < x <= 2. I'll probably provide some
test code and examples for dcop too. 

Actually, THANKS for inquiring about this - it always helps to
know what users want to see implemented.

Jim