Signals & Slots!

[qtoptus]

I'm wondering if the signal/slot approach to event handling is gonna be replaced by something that does not require the special pre-processing step? It may be a nice way to handle object events, but at the same time it's pretty limiting when it comes to editing designer generated code. Besides, it makes the code less standard and requires the Qt tools to do this extra step.

Is there a technical reason for sticking with this approach? Why not use traditional event handling like in other toolkits?

Will it be out of the way soon in future releases?

Is it already replaced and I'm not aware of this because I'm a begginer :)?

Thanks.

[squidge]

I doubt it'll be going anywhere soon as it offers much more than other methods used in other toolkits.

Some webpages you might want to read: A wikipedia article! (http://en.wikipedia.org/wiki/Signals_and_slots) and the qt documentation for signals and slots (http://doc.trolltech.com/4.6/signalsandslots.html)

[wysota]

Let's not forget signals & slots mechanism allows for loose coupling of objects whereas regular events require more tight coupling (at least being tightly coupled to the event objects themselves). Signals are also referred to as "semantic events" being more high-level than regular events (i.e. "scrollbar's groove was clicked" vs. "left mouse button was pressed at position [24,42]"). And having MOC around is not a burden, many people don't even know it's there. There are other precompilers or postcompilers involved so one more or less doesn't make a difference. Also thanks to a runtime evaluation of Qt's signals and slots and metaobjects in general they can be safely used across library boundaries and can even be dynamically created (i.e. for D-BUS or COM exposure).