[Development] [Interest] XCB clipboard freeze

[Benjamin TERRIER]

Le mar. 5 nov. 2019 à 17:39, Thiago Macieira <thiago.macieira at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20191113/d2047976/attachment.html>