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