views:

84

answers:

2

I'm wanting a paradigm in a Qt4 (PyQt4) program where a component is able to respond to a signal without knowing anything about where it is coming from.

My intial reading suggests that I have to explicitly connect signals to slots. But what I want is for any of a number of components to be able to send a signal, and for it to be processed by another component.

Comparing with another toolkits, for example, in wxWidgets I would use events. These automatically propogate up from child windows/objects to parents. At each level they can be handled. This means if I have a lot of children which may emit the same event, I don't have to explicitly connect all of them to the handler. I can just put the handler in the parent, or some higher level in the window hierarchy. This means that only the event generator and consumer need to know about the event at all. The consumer doesn't need to know where the source of the event is, how many such sources there are, or anything else about it.

Is this possible in Qt - is there another approach? Maybe there is an alternative event mechanism to signals and slots?

+1  A: 

This isn't easily possible - you have to have something that knows about the signaling object and the receiving object to connect the two. Depending on what you need, however, you might be able to set up a class that mediates between the two (so objects with signals tell the class they exist, and have such-and-such a signal, while objects with slots tell the class they exist and have such-and-such a slot to connect to a given signal, and the mediator class tracks both of those, making connections when necessary).

Caleb Huitt - cjhuitt
Yes .. I guess I could create a singleton class to server as a "postbox" for connecting the signal generators with the slot consumers. Maybe this is the correct design pattern for this scenario in Qt?
Chris Crook
The problem with a singleton though is that it is application wide. I may only want to respond to signals generated by children of a dialog box, or other container, but not to similar objects elsewhere in the application. If I try and apply this approach within a dialog box, then either the signal generators needs to know who is interested in their signals, or the slot consumers need to know when new signal generators are created, so they can connect to them. Either of which breaks the component modularity :-(
Chris Crook
A: 

Don't you just want a good old fashioned method invocation? The response is just the return value of the method.

goertzenator
No. What I'm looking for is a more like a broadcast event. The impression I'm getting is that Qt supports an object oriented paradigm well, but not really an event driven paradigm.Signals and slots allow a looser coupling than method invocation - the signalling object and slot receiver don't need to know about each other. But an object somewhere does need to know about both of them, in order to connect them.
Chris Crook
What I am looking for is looser still - nothing connects the event generator and the consumer. The generator creates an event. The consumer listens for events. The consumer may signal that it has handled the event. The event is available to potential consumers in a defined order based upon their location in the application windows tree (ie parent/child windows). I think that Qt doesn't do anything like this?
Chris Crook
I'd say python makes function calls quite loose, but I think what you mean is automatic association of the generator and consumer. In this case association is based on parent/child relationship.Another idea: At construction time, have the generator object (the child) look upwards through the widget hierarchy to find the consumer. Store a ref to the consumer in the generator, and call its methods at will.
goertzenator
Thanks - that was the sort of thing I was looking for, though in my case the event source is a lower level widget and probably should not know about the potential consumer. It may be possible for the consumer to use an event filter to trap the construction of (indirect) children of interest and connect to them. I think the implementation suggested above by rebus (using a QCustomEvent and overriding QApplication::notify) may be cleaner though.
Chris Crook