Event Rationale

[pseudonym67]

Hi
I'm still plugging away at the book http://www.beginning-kdevelop-programming.co.uk/

At the moment I'm looking at events ( Keyboard presently )
I want to know if anyone can explain the rationale for having events as virtual protected functions and not as slots which would be considerably easier for people to access them than the current situation where the only way to access them is to subclass the base class.

[jacek]

How would they access them and what for?

You have to pass some event as a parameter to every event handler and most of the events come from Qt's heart. Users rarely need to create them. If you want to do something with an event handler, it's because you want to change the behaviour of a widget and this calls for a new class. If you just want to use it, normal methods, slots and signals should be enough. They are more convenient too.


Edit: I've just skimmed through your book. You have a memory leak in ChapterFiveDataTableWidget::polish() on page 150. Better create that password dialog on the stack.

[Michiel]

I think you misread pseudonyms post. He/she is asking why events are as they exist in Qt now, when signals could have been used instead.

I'm not exactly sure why (though I would hazard a guess at performance loss).

However, subclassing is not the only way to catch an event. You can also use event filters.

[jacek]

I think you misread pseudonyms post. He/she is asking why events are as they exist in Qt now, when signals could have been used instead.

Maybe, but in such case the explanation is simple. Without events Qt wouldn't be an even-driven programming framework --- signals and slots are synchronous (except for queued connections, but these use events underneath).

[Brandybuck]

Events do not have any meaning to them. The user has done something: press a key on the keyboard, moved a mouse, etc. Signals do have semantic meaning, however. Objects take these meaningless events and make signals out of them. For example, a QPushButton has been pressed.

Would you really want a mouseMoved() signal every time the mouse moved a pixel along the screen? Of course not! Qt keeps all of that low level chatter down in the event system. You typically only have to worry about them when you're writing new QWidgets.

[pseudonym67]

The case in point is a demonstration project to handle key presses the point is that as signals if you wanted to interpret key presses or mouse move events then you could do it without subclassing.
If I understand it correctly this is exactly what event filters allow you to do.