Implement X11 'INCR' protocol for sending large clipboard data

[Albrecht-S]

FLTK implements the X11 'INCR' protocol for receiving data from selections (e.g. the CLIPBOARD) from other X clients.

However, the INCR protocol for sending its own clipboard data to other clients (when the FLTK program is the clipboard owner) is not implemented. Instead, FLTK tries to send the data with a single XChangeProperty() call which requires to set the entire clipboard data as one window property. This works only for small clipboard contents but not for large data. There's currently no error checking. In case of an error the data is not sent.

My tests on Linux Mint 20 show that the limit is somewhere in the range of ~15 MB. I'm not aware of a hardcoded or settable limit of this size in the X server. I found out that other X clients send clipboard data via the INCR protocol in chunks of 1 MB which might be a "safe" value although the limit might also be lower on other systems. This needs more investigation.

[Albrecht-S]

FWIW: Tests revealed that the largest possible clipboard size which can currently be transferred successfully on my system is 16.777.184 Bytes, i.e. 16 MiB - 32 or 16 * 1024 * 1024 - 32 Bytes.

[ManoloFLTK]

For information: FLTK's new Wayland platform can successfully copy a 17-MB text from FLTK's editor program to gedit.

[Albrecht-S]

@ManoloFLTK I see. This is much more straightforward (writing to a socket) than the implementation of the ugly INCR protocol. Anyway, I'm working it...

[Albrecht-S]

FYI: Today I made good progress and managed to transfer a 4 MB selection (clipboard) to four different clients via INCR protocol (in chunks of 1 MB). I also tried a 19 MB selection and it worked fine.

With the new code FLTK can transfer large selections in both directions, e.g. from one test/editor to another test/editor instance (I used a simplified test program for my tests).

Current status: works but needs cleanup and better integration into the event loop.

[Albrecht-S]

FTR: Meanwhile I got a proof of concept working ... somehow. It works for transferring selection data in the same way as the current function to receive clipboard data: it uses a separate function which is decoupled from the internal event loop and polls its own events. Unrelated events are ignored in this case which works but is not a proper solution. There's also no built-in error handling for uncooperative other clients, i.e. if the "other" client who sends clipboard data does this in an infinite loop bad things may happen.

To do: I strive to integrate these two features (sending and receiving of clipboard data using the INCR protocol) in the main event loop which should be possible but needs some more work.

[Albrecht-S]

Note: the remaining issue is low priority because the functionality (INCR protocol for large data from and to the clipboard) exists and works.

The benefit we'd get by integration in the normal event loop would be a better event handling but very likely unnoticed in real life. Still worth taking another look though...