On Mon, Jun 27, 2016 at 12:08:43AM +0200, Enrico Forestieri wrote:
> On Sun, Jun 26, 2016 at 11:33:53PM +0200, Enrico Forestieri wrote:
>
> > On Sun, Jun 26, 2016 at 02:50:28PM -0400, Scott Kostyshak wrote:
> >
> > > On Sun, Jun 26, 2016 at 01:51:58PM +0200, Enrico Forestieri wrote:
> > >
> > > > > Can anyone else reproduce?
> > > >
> > > > I cannot. It works for me even compiling lyx as an X11 application
> > > > on cygwin (using Qt5) and middle-pasting to native windows applications
> > > > that support it, such as gvim.
> > >
> > > OK so it might be specific to X11 on Linux.
> >
> > Actually, I don't see it neither on linux nor on solaris. Maybe it is
> > due to the fact that I use a focus-follows-mouse policy.
>
> Yes, that was it. After I change to focus-click the first middle click
> does not paste anything but simply gives focus to the window and the
> message you reported earlier is printed in the terminal from which lyx
> was started. Still, this doesn't happen on cygwin and I have no idea
> why it happens, yet.
I had a closer look at this issue. First of all, it occurs with both
Qt4 and Qt5, the only difference being that Qt5 prints a warning.
Then, it does not occur with all applications. I can reproduce with
gnome-terminal and gedit, but cannot reproduce with gvim, for example.
It only occurs after selecting something in lyx and trying to paste to
another application for the first time. Then the paste succeeds on a
second attempt, even if the window has not the focus anymore. However,
selecting something else in lyx, it starts over again.
I came up with the attached patch that solves the issue for me.
It requires the Qt5X11Extras module, which is not mandatory, though.
The patch simply tries to refresh the timestamp of the selection request.
I still get the warning from Qt5 (even if only once), but the paste by the
middle mouse button succeeds anyway. Recall that this issue does not occur
with a focus-follows-mouse policy. Given that it also does not occur with
some applications, I don't know who is to blame for this.
The patch is for Qt5 and autotools only (I don't know cmake, sorry).
--
Enrico
diff --git a/config/qt4.m4 b/config/qt4.m4
index 0e357a4..5d0a306 100644
--- a/config/qt4.m4
+++ b/config/qt4.m4
@@ -209,6 +209,13 @@ AC_DEFUN([QT_DO_PKG_CONFIG],
if test "x$USE_QT5" != "xno" ; then
qt_corelibs="Qt5Core"
qt_guilibs="Qt5Core Qt5Concurrent Qt5Gui Qt5Svg Qt5Widgets"
+ lyx_use_x11extras=false
+ PKG_CHECK_EXISTS(Qt5X11Extras, [lyx_use_x11extras=true], [])
+ if $lyx_use_x11extras; then
+ qt_guilibs="$qt_guilibs Qt5X11Extras xcb"
+ AC_DEFINE(HAVE_QT5_X11_EXTRAS, 1,
+ [Define if you have the Qt5X11Extras module])
+ fi
lyx_use_winextras=false
PKG_CHECK_EXISTS(Qt5WinExtras, [lyx_use_winextras=true], [])
if $lyx_use_winextras; then
diff --git a/src/frontends/qt4/GuiApplication.cpp b/src/frontends/qt4/GuiApplication.cpp
index 6586207..d1541cf 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -125,6 +125,9 @@
#undef None
#elif defined(QPA_XCB)
#include <xcb/xcb.h>
+#ifdef HAVE_QT5_X11_EXTRAS
+#include <QtX11Extras/QX11Info>
+#endif
#endif
#if (QT_VERSION < 0x050000) || (QT_VERSION >= 0x050400)
@@ -3166,8 +3169,23 @@ bool GuiApplication::nativeEventFilter(const QByteArray & eventType,
BufferView * bv = current_view_->currentBufferView();
if (bv) {
docstring const sel = bv->requestSelection();
- if (!sel.empty())
+ if (!sel.empty()) {
d->selection_.put(sel);
+#ifdef HAVE_QT5_X11_EXTRAS
+ xcb_selection_notify_event_t nev;
+ nev.response_type = XCB_SELECTION_NOTIFY;
+ nev.requestor = srev->requestor;
+ nev.selection = srev->selection;
+ nev.target = srev->target;
+ nev.property = XCB_NONE;
+ nev.time = XCB_CURRENT_TIME;
+ xcb_connection_t * con = QX11Info::connection();
+ xcb_send_event(con, 0, srev->requestor,
+ XCB_EVENT_MASK_NO_EVENT,
+ reinterpret_cast<char const *>(&nev));
+ xcb_flush(con);
+#endif
+ }
}
break;
}
