[Interest] subclassed QTimer

[René J. V. Bertin]

René J.V. Bertin wrote:

Hi,

Sorry for forgetting completely about this thread, my bad. It turned out that I 
hadn't completely understood the editor class. Rather than having a single 
instance of that class and then a list of open documents, there is actually a 
list of instances of that editor class. That means I don't need to maintain my 
own class of timers, and also that I could simply add a timer slot to the editor 
class, because each editor instance needs to poll the state of only a single 
document.

Now, to react to the suggestions:

> Yeah. It simply doesn't make a lot of sense. What is the function of the 
> public fired() slot? And why do you connect to that from outside of the 
> timer class itself? What is the function of stuffing the timers in a 

The fired() slot is the actual thing that I thought I needed, one for each open 
document. It seemed a lot of work to add a timer slot to the editor class 
itself, plus a mechanism to ensure that that slot gets called with the 
appropriate reference to the document to be checked.
I could have defined a small class holding a reference to the Item, plus a 
timer; instead, I thought I'd try to subclass QTimer itself.
You're right, I could have do the connect() in the QItemTimer ctor.

> list instead of giving them a parent? Why do you need polling at all to 
> check the state of the "various items"?

That's a bit not the point, no? :)
This is code ported from Linux to OS X; on Linux, a daemon would in fact control 
the state I'm interested in, and send notifications via the DBus when the state 
changes. On OS X, that state is controlled in decentralised fashion, think 
applications getting a handle on the items in question.
To be exhaustive: the editor is KDE's KWallet Manager, the items are wallets, 
"hosted" as OS X keychains via a kwallet backend I wrote and that only supports 
so-called synchronous operations. The state is whether the wallet is open or 
closed (locked).

> I'm missing the Q_OBJECT macro

That would only be required if QTimer doesn't already have one (it does), right?

> Why are you subclassing QTimer and not just use it  as it is ??

See above, I needed to add a timeout slot somewhere, thought I best define a new 
class for that. The reason I subclassed QTimer rather than defining a class with 
a QTimer member variable? It seemed more elegant, and also that it should work.

And I'm still curious as to why it didn't work, no matter how weird it might 
seem. Surely there must be use cases where you can't add a slot to the class 
that should logically have it (because it's closed source, because it's provided 
by a system library, because C++ isn't ObjC which does allow extending existing 
classes, whatever). I still think it's more elegant in that kind of situation to 
have a timer object that also has the timed method, rather than a new object 
that contains a timer and the timed method. In terms of compiled code it 
probably doesn't make a significant difference at all, if any.

R.