Windows (native GUI) hangs, then prints `event.ReqClipboardDataSet: receive timeout`

Hi. Sorry if creating this issue is annoying. Feel free to delete it if you want.

I downloaded the Windows release of v1.1.0 to try it out. After unzipping and running it, some actions in the UI cause it to free for 3 seconds or more at a time. For example, dragging the mouse to select text will cause the UI to freeze for a long time, then eventually print

error: cpcopy: win appdata: *event.ReqClipboardDataSet: receive timeout
error: cpcopy: win appdata: *event.ReqClipboardDataSet: receive timeout
error: cpcopy: win appdata: *event.ReqClipboardDataSet: receive timeout
error: cpcopy: win appdata: *event.ReqClipboardDataSet: receive timeout
error: cpcopy: win appdata: *event.ReqClipboardDataSet: receive timeout
error: cpcopy: win appdata: *event.ReqClipboardDataSet: receive timeout
error: cpcopy: win appdata: *event.ReqClipboardDataSet: receive timeout
error: cpcopy: win appdata: *event.ReqClipboardDataSet: receive timeout
error: cpcopy: win appdata: *event.ReqClipboardDataSet: receive timeout
error: cpcopy: win appdata: *event.ReqClipboardDataSet: receive timeout
error: cpcopy: win appdata: *event.ReqClipboardDataSet: receive timeout
error: cpcopy: win appdata: *event.ReqClipboardDataSet: receive timeout
error: cpcopy: win appdata: *event.ReqClipboardDataSet: receive timeout
error: cpcopy: win appdata: *event.ReqClipboardDataSet: receive timeout

in a +Messages window. Which makes the editor not usable. This is in Windows 10.

I realize this is your own personal project, so I'm only posting this in case it's some problem you weren't aware of but is easy to fix. I can provide more information or testing if you want. If this problem isn't something you want to deal with, don't worry about it. I was just trying this editor for fun, and thought you might want to know about this issue I experienced.

Thanks for reporting, honestly. I have no other way of knowing if stuff is broken.

At a first glance, I suspect you tried to copy a big chunk of data? That msg is about the windows loop not returning in time about the clipboard request.

The timeout line:

editor/driver/windriver/window.go

Line 378 in 8acc573

reqErrV, err := appData.Ch.Receive(3 * time.Second)

And the function taking too long:

editor/driver/windriver/window.go

Line 721 in 8acc573

func (win *Window) ostGetClipboardData() (string, error) {

The UI should not freeze in either way (unless the OS is not coming back from that func call) so it does need to be fixed.

Will need to take a closer look. Leaving this open.

It happens even when selecting only a few characters of text. I recorded a GIF to demonstrate.

So the issue was apparently here:

editor/driver/windriver/window.go

Line 906 in 8acc573

return &AppData{chanutil.NewNBChan2(0, logStr), v}

It was forcing the whole requests to sync and making the UI slow without need.
The fix is just changing the buffer from zero to one.

You can get the v1.1.0 version source, go to that line, change to "1", and see if it fixes, or just get the latest from the master branch (but it currently contains other changes).

I've been testing the windows version under qemu, so I just gave the discount that it was running under an emulator, but I should have seen this sooner.

Let me know if it did improve. The windows version was actually unusable without this fix indeed, and the change to the channel mechanism was done already awhile ago (56be141 if git blame is serving me right).

Just for further documentation of this issue: the xdriver uses a similar mechanism but it has the buffer at one, so it was not affected.

editor/driver/xdriver/wimage/shmwimage.go

Line 33 in 8acc573

wi.putCompleted = chanutil.NewNBChan2(1, "shm putcompleted")

Also, the reason why the whole "clipboard" gets involved, is all that is needed to create a copy of text is to "select" the text (called a primary selection). This is standard behavior in linux to use the mouse to select, and then middle click to paste.

So this mechanism goes all the way to the driver but the windows driver then ignores it (it just copies on the clipboard selection with ctrl+c).

Still, the request for the copy goes to the driver.

I downloaded the v1.1.0 source, made the single change you suggested, and built it. It does indeed fix the issue in my environment. Thank you!