Events vs signal-slot system

brkonator

Hello, I was wondering, why some Qt "events" can only be processed using the event system (e.g. QMouseEvent) and some using the signal-slot system (e.g. QPushButton::clicked - I know, this could also be simulated using mouse press and release events but still - it's a separate signal instead of an event). Is this mostly because of performance reasons? Is there some other reason? Thanks in advance.

sierdzio

I think the reason why events are used where they are is because of 2 things:

events are closely related to and integrated with Operating System events - it's simply easier to implement and to think about system events using QEvent than it would be with signals and slots
events are pretty much globally available and more low-level

Is this mostly because of performance reasons?

I don't know, but I doubt it.

Kent-Dorfman

yeah. they are apples an oranges. there is a well defined deliniation between signals and events but it's hard to explain. events are generally triggered by hardware or OS "events" or things that may be based on an interrupt of some sort. signals are purely application level triggers to fire some method based on engineered behavior. there is some overlap, such as timer timeouts but in general think of the events as functions that are triggered by quazi-interrupts or OS level triggers.

sierdzio

An interesting point here is, I think, that in theory Qt could be rewritten to use only signals and slots. There would have to be some global (yikes!) QMouse object which would be sending mouse signals, global keyboard object which would send key signals etc.

Kent-Dorfman

@sierdzio Sure. I can think of other similar frameworks using that approach, but they are nowhere near as sophisticated of mature as Qt.

brkonator

Thanks for your replies, it's much clearer to me now.

kshegunov

@sierdzio said in Events vs signal-slot system:

An interesting point here is, I think, that in theory Qt could be rewritten to use only signals and slots.

Probably not, but even if you're right it's going to be one grimy mess. One "big thing" about events is that you can propagate them through the object tree, which I've used in a project last year. My use case was more or less a composition of entry and exit points for a network comm interface, where you could (and have) multiple sources and sinks, and attach at different points of the "pipeline". In that case I was both sinking and bubbling up the events through the object tree aplenty, that's not that straightforward to design with signal/slots only (which I used as my "extraction points").

@brkonator
Events are lower level, they usually refer to the object itself and you're rarely going to see QCoreApplication::sendEvent or QCoreApplication::postEvent used explicitly, although it does happen. Signal-slot connections are more like callbacks, much more mature and nice (obviously). As a matter of fact some signal-slot connections are executed through an event, specifically the queued connections' executions are packed in a QEvent::MetaCall event internally.