PyQt and DCOP Documentation

[Eric Williams]

Jim Bublitz wrote:

> 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



-- 
---
s- should be removed to contact me...