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. _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
