PyQt and DCOP Documentation

Discussion in 'Python' started by Eric Williams, Nov 10, 2003.

  1. 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()





    --
    ---
    s- should be removed to contact me...
     
    Eric Williams, Nov 10, 2003
    #1
    1. Advertising

  2. Eric Williams

    Jim Bublitz Guest

    Eric Williams wrote:

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


    >>> from qt import QByteArray
    >>> qb = QByteArray ()
    >>> qb.duplicate ("Hello")

    <qt.QByteArray instance at 0x819d7fc>
    >>> qb.data()

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


    http://mats.imk.fraunhofer.de/mailman/listinfo/pykde

    Jim

    > 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()
     
    Jim Bublitz, Nov 10, 2003
    #2
    1. Advertising

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

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

    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

    --
    ---
    s- should be removed to contact me...
     
    Eric Williams, Nov 10, 2003
    #3
  4. Eric Williams

    Jim Bublitz Guest

    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
     
    Jim Bublitz, Nov 10, 2003
    #4
  5. 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...
     
    Eric Williams, Nov 10, 2003
    #5
  6. Eric Williams

    Jim Bublitz Guest

    Eric Williams wrote:

    > 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
     
    Jim Bublitz, Nov 10, 2003
    #6
  7. Eric Williams

    Fedor Sumkin Guest

    Jim Bublitz wrote:

    > Eric Williams wrote:
    >
    >> 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


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

    > 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


    --
    Best regards
     
    Fedor Sumkin, Nov 11, 2003
    #7
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    307
    R. C. James Harlow
    May 8, 2005
  2. Replies:
    2
    Views:
    331
  3. Jeffrey Barish

    Using DCOP from Python

    Jeffrey Barish, Dec 18, 2006, in forum: Python
    Replies:
    1
    Views:
    543
    David Boddie
    Dec 19, 2006
  4. DCOP memory leak?

    , Jan 30, 2007, in forum: Python
    Replies:
    5
    Views:
    313
  5. News123
    Replies:
    0
    Views:
    512
    News123
    Nov 9, 2008
Loading...

Share This Page