Text selection does not work as expected

[Yu Jin]

Am Sa., 4. Juli 2020 um 22:02 Uhr schrieb Scott Kostyshak <skostysh at lyx.org
>:

> On Sat, Jul 04, 2020 at 07:50:18PM +0200, Yu Jin wrote:
> > Am Sa., 4. Juli 2020 um 17:16 Uhr schrieb Scott Kostyshak <
> skostysh at lyx.org
> > >:
> >
> > >
> > > Thanks for looking into this, Eugene. Just to make sure I understand,
> > > you think this is a Qt bug, right? I don't know anything about this
> > >
> >
> > It looks like a Qt bug indeed, I have reported it on Qt bugtracker.
>
> Great, thanks for doing that. I suggest to put the URL to the Qt bug
> report when you commit.
>
> > But to
> > clarify, the bug occurs only on touchpads (not on Windows 10 in general).
> > I have tested an older LyX version on my notebook, 2.3.1 (with Qt 5.10.1)
> > -> no bug. The newer LyX versions, which come with Qt 5.12.5 and also my
> > latest betainstaller, where I used Qt 5.15.0, do have that bug, therefore
> > it seems like a Qt bug.
> >
> >
> > > stuff, so hopefully a different LyX developer takes a look. Don't spend
> > > time making a new patch based on my comments (wait for another LyX dev
> > > first), but if you do get a +1 to commit, it would be nice to mark
> > > exactly what parts of the code are in there because of a workaround for
> > > a Qt bug, and how to test that the bug is no longer relevant (e.g., "to
> > > test if this workaround is still needed, try to select a word by
> > > double-clicking in LyX on Windows 10. For more information, see the
> > > following ML thread...").
> > >
> > > Taking a step back, what changed that triggered this bug? I'm guessing
> > > that it is because we compiled LyX 2.3.5 with a newer Qt version. Is
> that
> > > correct? Is it worth compiling 2.3.4 on your machine to double-check
> that
> > > you *can* reproduce the bug (since using a newer Qt version)? What Qt
> > > version was 2.3.4 compiled with? I personally would support putting the
> > > added lines in preprocessor guards but I don't know how other LyX
> > > developers feel about that. Here is the flavor of preprocessor checking
> > > that I think is easiest:
> > >
> >
> > I have compiled master with Qt 5.15.0 on my machine, resulting in the bug
> > occuring. Compiling master with Qt 5.9.9 (I could not download 5.10.1, to
> > match what is used in the LyX version I have tried above, for some
> reason)
> > didn't produce the bug.
>
> Thanks for those checks.
>
> > > #if (QT_VERSION < QT_VERSION_CHECK(5, 0, 0))
> > >        // code here...
> > > #endif
> >
> >
> > I see and understand now that workarounds for Qt bugs are not easy to
> > handle. Also I can't predict when or if the bug will be fixed in Qt. So
> > what is attached is what I can provide for now, maybe other developers
> have
> > more experience or better ideas?
>
> So something like the following could work (but I haven't tested):
>
> #if (QT_VERSION > QT_VERSION_CHECK(5, 9, 9))
>        // we do not see the bug with 5.9.9 and do see it with 5.15.0
>        // Qt bug report: <URL>
>        ...
> #endif
>
> > Btw do we have some kind of tracker for
> > this kind of issues?
>
> I think in trac we have (or at least had) a keyword "qtbug". But we were
> never too careful about using it.
>
> If no one else responds within a couple of days, if you make a patch
> with the Qt version guards, I think I would feel comfortable taking a
> closer look and would likely give a +1.
>

Here we go, patch attached. I decided to put Qt version check 5.10.1,
because I have tested it on LyX 2.3.1, which was shipped with Qt 5.10.1 and
the bug was not there yet.

Eugene
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20200708/b6e59d13/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MouseMoveEvent.diff
Type: application/octet-stream
Size: 1658 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20200708/b6e59d13/attachment.obj>