<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 5 nov. 2019 à 17:39, Thiago Macieira <<a href="mailto:thiago.macieira@intel.com">thiago.macieira@intel.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Probably *because* events would be processed during the wait. We all know <br>
nested event loops are bad design. In this case, this stems from another bad <br>
API design: the clipboard handled synchronously, when it clearly isn't.<br>
<br>
Note: I don't know the QClipboard API. This could be just the backend, in <br>
which case my explanation is wrong and the QXcbClipboard should be refactored <br>
to operate reactively. As Linux kernel core developer Alan Cox said, "threads <br>
are for people who can't program a state machine".<br>
<br></blockquote><div><br></div><div><br></div><div>I worked a little bit on QXcbClipboard and I was able to make it work asynchronously.</div><div>This solves my issue of freezing.</div><div><br></div><div>However, since the QClipboard API is synchronous there is no place and time to make the asynchronous work</div><div>when the user is requesting content.</div><div><br></div><div>So my solution is to fetch the clipboard content asynchronously when Qt receives clipboard events from X11.</div><div>The drawback is that whenever a user copy something to the clipboard, the Qt application will automatically fetch</div><div>this something and therefore consume memory to store the content. This might be a negligible issue when</div><div>copy/pasting short texts, but this will certainly be an issue if when someone copies a 100MB image, all the</div><div>Qt applications allocate 100MB.</div><div><br></div><div>I guess unless we change QClipboard API to make it async (like in GTK) I do not see how to solve this issue.</div><div><br></div><div>BR</div><div><br></div><div>Benjamin<br></div></div></div>