#2821 Keyboard & mouse commands not working with Qt6 on Windows

[Bastian Märkisch]

Currently gnuplot is built only with Qt5 on Windows, so this is not an issue for the binaries.
With Qt6, plotting works fine. But the communciation between gnuplot and gnuplot_qt only seems to send, but not receive data. Hence mouse and keyboard commands do not work. The relevant code in qt_waitforinput() is specific to Windows (and has to be).

[Ethan Merritt]

Both gnuplot and gnuplot_qt send and receive to each other, so there are four communication paths. I am trying to understand or help diagnose which of them is failing.

If plotting works, I take it that means commands are successfully sent from gnuplot to gnuplot_qt.

When you say keyboard commands do not work, what does that mean exactly? Commands after the initial "plot" command are ignored? Keyboard is locked up? New commands work but hot-keys (bind commands) do not?

Does the plot window (gnuplot_qt) respond to mouse events that don't require communicating with the main process (gnuplot)? E.g. can you use the toolbar widget to save a plot to a file?

I assume there's some way in Windows to force the plot window closed by using a system command or clicking on a decoration somewhere? If you do that, does the main program recognize that the window needs to be re-opened on the next plot command? If so, that would indicate it's receiving at least some feedback from the child process.

There are a bunch of qDebug statements in QtGnuplotEvent.cpp. If you un-comment them are recompile, do any of them trigger and show something helpful?

[Bastian Märkisch]

The failing communication path is gnuplot receiving events from gnuplot_qt. There's never a call to qt_processTermEvent(), whereas on the sending side QtGnuplotEventHandler::postTermEvent is called and writes to the socket. Adding a flush() after write() does not help.

Interestingly, receiving fontprops in qt_sendFont() works. But the code in qt_waitforinput() which is supposed to read events from the gnuplot console, or the wgnuplot text window, and the windows or wxt terminals, and the qt socket fails to receive any events.

The way that code is supposed to work (and did with Qt5) is that it uses MsgWaitForMultipleObjects() to "listen" to and wait for multiple "handles", i.e. sources of input. With Qt it never seems to return the socket handle, though. I suspect the internals of QtLocalSocket on Windows changed somehow and we can no longer wait on the socketDescriptor(). According to the Qt docs https://doc.qt.io/archives/qt-5.15/qlocalsocket.html#socketDescriptor and https://doc.qt.io/qt-6/qlocalsocket.html#socketDescriptor this should not be the case, though. It is still a Winsock 2 Socket Handle.

A work-around could be polling the qt socket as it is done in qt_sendFont() and adding a (small) timeout to the MsgWaitForMultipleObjects() call.

[Bastian Märkisch]

.Turns out that the issue was the zero argument to QtLocalSocket::waitForReadyRead(). Changing this to a small number of milliseconds (>0) fixes the issue. Commit in master branch along with changes to config/mingw/Makefile to enable compilation with Qt6.