> On 17 Apr 2015, at 2:46 pm, Alejandro Exojo <s...@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

_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Reply via email to