PyQt and DCOP Documentation

E

Eric Williams

Is there any reasonable documentation (i.e., with full examples and/or code
snippets or argument lists or anything) to be found for using python with
Qt/DCOP? "Fully Implemented." does not constitute complete documentation
when you're c++ illiterate.

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?

Thanks a bunch,
Eric


(current non-functioning attempt below)
---------------
class Noatun(dcop.DCOPClient):
def __init__(self):
dcop.DCOPClient.__init__(self)
self.appname="NoatunPeeker"
self.attach()
self.registerAs(self.appname)
if self.isAttached():
self.rc = dcop.DCOPRef("noatun","Noatun")
else:
print "Couldn't attach!"
sys.exit(1)

def getvol(self):
res = self.rc.call("volume()")
if res.isValid():
return str(res.data)
#returns '(' why?
else:
return "Couldn't call"

def gettitle(self):
res = self.rc.call("title()")
if res.isValid():
return str(res.data)
#works as expected
else:
return "Couldn't call"

if __name__=="__main__":
n = Noatun()
print n.getvol()
print n.gettitle()
 
J

Jim Bublitz

Eric said:
Is there any reasonable documentation (i.e., with full examples
and/or code
snippets or argument lists or anything) to be found for using
python with
Qt/DCOP? "Fully Implemented." does not constitute complete
documentation when you're c++ illiterate.

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?
'Hello'

But you should be able to use a Python string anywhere you need a
QByteArray, so the above shouldn't be necessary.

I'll check out the rest, but I'll have to see if I have noatun
working first - may take a little while to get to it
(dinnertime).

PyQt is supported on the PyKDE list:

(e-mail address removed)
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde

Jim
 
E

Eric Williams

Eric said:
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

-----------------------------------------------

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?

Thanks,
Eric
 
J

Jim Bublitz

Eric said:
Eric said:
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()

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
 
E

Eric Williams

Jim said:
Eric Williams wrote:

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.


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)

------------------------
Thanks a lot, Jim, that's exactly what I needed.

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


Done. I'll really have to brush up on my c++, though; now that I'm getting
a clearer picture of the api's I'm starting to grasp it a little better.


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

------------------------

I can't believe you're the only person working on this stuff; with the
amount of good work that's already gone into it, together with how useful
an application it really is, I'd figured there was a whole gaggle of people
on it.

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

I just subscribed to the list. For the size and nature of the KDE project,
the docs aren't bad at all. My statement above was simply that I'm in way
over my head for the most part, mainly due to my general inability to
program :-(

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

Thank you for taking the time to explain it. Thanks to your work and the
overall KDE-coolness I'm well on the way to turning lirc into a useful
application :)

cya,
Eric
 
J

Jim Bublitz

Eric said:
Jim Bublitz wrote:
Thanks a lot, Jim, that's exactly what I needed.

It's actually kind of ugly - it'll get better. You can't get any
return values from "ca;;" at the moment.
Done. I'll really have to brush up on my c++, though; now that
I'm getting a clearer picture of the api's I'm starting to
grasp it a little better.

The most recent release has (in my opinion - we'll see what
others think) greatly improved docs. This has been a frequent
complaint, and one that's hard to fix. The new docs do at least
list all of the methods in a Python format and they can be
linked to the KDE docs for text explanations.
I can't believe you're the only person working on this stuff;
with the amount of good work that's already gone into it,
together with how useful an application it really is, I'd
figured there was a whole gaggle of people on it.

I do PyKDE, Phil Thompson does sip and PyQt and did the original
PyKDE. Some of the newer stuff (plugins) has been done mostly by
other people, and I get a lot of good bug reports, patches, help
with build details, etc. Plus lots of automation.
I just subscribed to the list. For the size and nature of the
KDE project, the docs aren't bad at all. My statement above
was simply that I'm in way over my head for the most part,
mainly due to my general inability to program :-(

On the one hand better docs are a hard problem, on the other
hand, one of the main goals of this project is to make KDE
programming easy for anybody. You're not a newbie if you mostly
figured out dcop (and the parts you got hung up on ARE poorly
documented), but don't hesitate to post ANY questions on the
PyKDE list. People there are generally helpful (just as they are
here). You can look back in the archives for some of the dumb
questions I've asked there.

Check the developer section of kde.org for tutorial stuff too.
Also, the Qt docs are excellent (but still C++).
Thank you for taking the time to explain it. Thanks to your
work and the overall KDE-coolness I'm well on the way to
turning lirc into a useful application :)

My pleasure - I'm sincere about appreciating your posts too.
Hopefully the next release will be better suited to what you
want to do. I've always wondered if this stuff worked or not,
but never found a reason to look into more.

Personally I think this is really cool too, which is why I picked
up the project when Phil ran out of time to maintain it.

Jim
 
F

Fedor Sumkin

Jim said:
It's actually kind of ugly - it'll get better. You can't get any
return values from "ca;;" at the moment.


The most recent release has (in my opinion - we'll see what
others think) greatly improved docs. This has been a frequent
complaint, and one that's hard to fix. The new docs do at least
list all of the methods in a Python format and they can be
linked to the KDE docs for text explanations.


I do PyKDE, Phil Thompson does sip and PyQt and did the original
PyKDE. Some of the newer stuff (plugins) has been done mostly by
other people, and I get a lot of good bug reports, patches, help
with build details, etc. Plus lots of automation.


On the one hand better docs are a hard problem, on the other

You can use PyQtDoc from theKompany.com.
It is changed Qt documentation which cover PyQt.
It also contains examples and tutorials.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top