Sam wrote:Hi George,

Is there a separate signal hook for the QM's "Decrease priority of torrents which are stalled for too long"?

Not at the moment, I can add such a signal after the 4.0 release.

I'm also planning to expand the scriptability of the QM greatly. Given the fact that you are working on this, what kind of stuff would you like to see added ?

[quote="Sam"]Off the cuff... [kinda rambles]

I'd like Section 1, Sub-section A and Sub-section B of viewtopic.php?f=1&t=3496 . I'm currently using file paths for what should arguably be Group controlled, but it works fine, so Sub-section B can be delayed as you see fit.

And I'll update these in the original thread after hashing it out, but I'm going to suggest a change to KTorrent.torrentStatusChanged so that it returns both the previous status and the current status would be nicest.

Say?

Code: Select all

def statusChanged(self,tor,prevStatus,currStatus):
   ... someCode ...

tor.connect("statusChanged(QObject* )",self.statusChanged)


tor.status() in that thread probably needs a revisit, as I'm reasonably certain I haven't listed all the various statuses a torrent can be in.

In the 50 thousand foot view, having a KTorrent.torrentStatusChanged signal instead of individual signals per event, means that you won't need to keep adding signals for this and that, just update the tor.status definition list and let the scripts catch what they will. Yeah, it might make something of an ugly statusChanged def, but, I think it would be easier for everyone?

Noodling here, in the case of a "QM's "Decrease priority of torrents which are stalled for too long"" bumping a Seeding torrent...
prevStatus would be "Seeding" and currStatus would be "Queued for seeding" which would be easy to capture and direct to the appropriate code block.
[quote]

Internally there is already a statusChanged signal, but we don't keep track of the previous status at the moment. So adding some additional parameters and making the signal available to the scripts should not be that much work.

Sam wrote:Okay, I'd still like a case statement in Python, but IF blocks work just as well too...

Actually, it's possible to have part of the switch/case mechanism in python. The code I'm thinking of looks like this:

Code: Select all

class Test(object):
   def __init__(self):
      self.d = {}
      self.d['case1'] = self._case1
      self.d['case2'] = self._case2

   def switch(self, parm):
      if parm in self.d:
         self.d[parm]()
      else:
         print 'not found'

   def _case1(self):
      print 'case 1'

   def _case2(self):
      print 'case 2'

t = Test()

t.switch('case1')
t.switch('case2')
t.switch('else')


Note that if you want to access local variables in the different cases (without passing them on as parameters), you might want to define callbacks and dictionary within the switch method.

I used code like this a while ago to implement a plugin infrastructure. Plugins could hook into my code by replacing the callbacks in the dictionary.

Greets, seth