[Interest] Survey: do you override QCoreApplication::notify? Why?

[John Weeks]

> On 17 Apr 2015, at 2:46 pm, Alejandro Exojo <suy at badopi.org> wrote:
>>> 4) filter events being delivered (remove from queue / compress)?
>> 
>> We do this.
> 
> Could you elaborate a bit on how do you do it?

My answer was a bit short, wasn't it? I was responding to the part about filtering. We use only the ability to return true from the notify() function to mean "block this event". We don't try to remove anything from the queue.

In fact, sometimes this isn't enough- at least on Macintosh, a click in a window's title bar that activates a window doesn't pass through notify(), you only see the resulting windowActivated and windowDeactivated events.

We have a feature in which our customers can create an "almost modal" window- it's modal except that some other window is allowed interaction. This was done so that a customer can create a control panel (window with controls, like a modeless dialog) that allows the user of his control panel to interact with a graph window and with the control panel, in an otherwise modal state. So we filter mouse events (and other UI events) for windows other than the control panel or graph window.

Also, code in our internal language prevents UI interaction, except that certain keys or a click on an Abort button can cancel execution. That allows stopping an infinite loop, or a complex computation that might go on for a long time (one of our customers was asking for optimization tips because his code ran all night and didn't finish).

-John Weeks