Wireshark mailing list archives
Re: Should Qt SimpleDialog messages be posted to event queue?
From: Peter Wu <peter () lekensteyn nl>
Date: Thu, 9 May 2019 01:10:57 +0100
On Wed, May 01, 2019 at 12:23:16PM +0200, Tomasz Moń wrote:
Hello, While investigating the "extcap terminates without connecting to pipes" issue [1], I have noticed that the "interrupt-like" behavior is induced by the simple_dialog() call. The simple_dialog() calls exec() on QMessageBox which in turn executes the events from the message queue. See [2] for better explaination. One approach to solve the problem of "unwanted interruptions" would be to change simple_dialog() function to post user-defined event to the event queue. This would avoid the problem by limiting the number of places where the events from the event queue can be handled. In opinion such change impacts the overall user interface architecture. If simple_dialog() gets changed to post user-defined event, then the code that calls simple_dialog() will continue to execute before the message box gets displayed to the user. This can be surprising to some developers, but in my opinion it is much easier to handle such asynchronous message box behavior, than to handle the possible "interrupt-like" executions of different actions while another action executes. The message box can still be modal (blocking until the user closes it) in this approach. What do you think about changing simple_dialog() to be asynchronous? Is there some better approach?
I think it a reasonable idea, hopefully there are no significant cases where the caller expected it to block though. Obviously memory needs to be duplicated, but aside from that we also have a case like ui/qt/preference_editor_frame.cpp. Right now it shows an alert, and on pressing OK it will actually close the dialog. Something similar might apply to UATs. After the proposed change, the UI might have changed (dialog is closed). This might not be a bad thing though. What would be problematic is a flood of error messages. Right now there is an annoying bug that occurs when a packet capture file is overwritten while it is already open. This causes a continuous stream of dialogs which requires killing the process since the UI becomes unusable due to the dialogs. If events are posted, maybe it should coalesce or somehow block new errors in case of bugs like this one. Link: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4811 Kind regards, Peter
Best Regards, Tomasz Moń [1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15743 [2] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15743#c2
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Should Qt SimpleDialog messages be posted to event queue? Tomasz Moń (May 01)
- Re: Should Qt SimpleDialog messages be posted to event queue? Peter Wu (May 08)
- Re: Should Qt SimpleDialog messages be posted to event queue? Tomasz Moń (May 15)
- Re: Should Qt SimpleDialog messages be posted to event queue? Peter Wu (May 08)