Le mar. 5 nov. 2019 à 17:39, Thiago Macieira <thiago.macie...@intel.com> a écrit :
> > 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". > > I worked a little bit on QXcbClipboard and I was able to make it work asynchronously. This solves my issue of freezing. However, since the QClipboard API is synchronous there is no place and time to make the asynchronous work when the user is requesting content. So my solution is to fetch the clipboard content asynchronously when Qt receives clipboard events from X11. The drawback is that whenever a user copy something to the clipboard, the Qt application will automatically fetch this something and therefore consume memory to store the content. This might be a negligible issue when copy/pasting short texts, but this will certainly be an issue if when someone copies a 100MB image, all the Qt applications allocate 100MB. I guess unless we change QClipboard API to make it async (like in GTK) I do not see how to solve this issue. BR Benjamin
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest