On Tuesday, 5 November 2019 07:28:17 PST Benjamin TERRIER wrote: > Still I am curious of why a QWaitCondition was used, and not another > solution that would have kept event processing enables during the wait.
Probably *because* events would be processed during the wait. We all know nested event loops are bad design. In this case, this stems from another bad API design: the clipboard handled synchronously, when it clearly isn't. Note: I don't know the QClipboard API. This could be just the backend, in which case my explanation is wrong and the QXcbClipboard should be refactored to operate reactively. As Linux kernel core developer Alan Cox said, "threads are for people who can't program a state machine". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
