The current situation can be improved, e.g., the waiting for a server to respond can be done in a separate thread, without blocking the gui.
The problem is not easily solved by just slapping on a thread. The main part of the problem is that you suddenly have something else to tidy up. If the user clicks connect, and the program asynchronously starts a connect operation, one suddenly has to deal with the problem that the used may close the dialog before the connect succeeds and that the user may repeatedly click connect while a connect is underway. Blocking the event thread is an easy, but also very inelegant, way to solve the former, and maybe also the latter, problem.
With a background thread, the background thread has to wait for one of two things: connection completion (successful or not) and cancellation message from event thread. I know a single function for this in Win32, but I don't know enough about pthreads to know if it can do the same. The server will also likely experience more spurious connects, caused by users clicking cancel after the server has acknowledged the connect, but before the client received confirmation. It should be hardened for such things already for other reasons, but I don't know.
The said, I also do not know how easy it is for the main event thread to periodically poll the status of a non-blocking connect, but it is a possibility.
Not without creating an entirely different code path for those builds without pthread, turning the already nightmarish network code even more so. This is why I keep saying pthread should be made a requirement rather than an option.
With mingw64 configured with the posix thread model (as is the case with MSYS2), the standard C++ library forces a dependency on pthreads already. (I've posted a patch to force this dependency to be statically linked, since almost everything else is so by default.)
My complaints over threading has not so much been over a dependency on pthreads, as using threads in the most difficult way possible (concurrent operation on shared state), without any benefits over the old tried-and-tested single-threaded code. In this case, the threading would hopefully be in a part of the code I don't use anyway.
