Discussion:
LyX Qt 5 issues
Scott Kostyshak
2014-07-15 22:32:21 UTC
Permalink
It seems that switching to Qt 5 is still a bit away, but planning
early is always a good idea. I would like to start (if it exists
already, please let me know) either a wiki page or a trac issue
keeping track of issues that we think have to do with Qt 4 vs. Qt 5.
Hopefully for each issue related to LyX with Qt 5 we can list the
versions of Qt 5 and OS's for which we have confirmation the issue
exists.

It would be nice to not just list the bugs that switching to Qt 5
would bring, but also the fixes or elimination of workarounds that the
switch would bring.

Any thoughts on this?

Scott
Jean-Marc Lasgouttes
2014-07-16 09:04:47 UTC
Permalink
Post by Scott Kostyshak
It seems that switching to Qt 5 is still a bit away, but planning
early is always a good idea. I would like to start (if it exists
already, please let me know) either a wiki page or a trac issue
keeping track of issues that we think have to do with Qt 4 vs. Qt 5.
Hopefully for each issue related to LyX with Qt 5 we can list the
versions of Qt 5 and OS's for which we have confirmation the issue
exists.
It would be nice to not just list the bugs that switching to Qt 5
would bring, but also the fixes or elimination of workarounds that the
switch would bring.
The best is to open a tracking bug, and then a ticket for each
individual problem.

JMarc
Enrico Forestieri
2014-07-16 09:55:31 UTC
Permalink
This post might be inappropriate. Click to display it.
Stephan Witt
2014-07-16 10:32:38 UTC
Permalink
Post by Enrico Forestieri
Post by Jean-Marc Lasgouttes
Post by Scott Kostyshak
It seems that switching to Qt 5 is still a bit away, but planning
early is always a good idea. I would like to start (if it exists
already, please let me know) either a wiki page or a trac issue
keeping track of issues that we think have to do with Qt 4 vs. Qt 5.
Hopefully for each issue related to LyX with Qt 5 we can list the
versions of Qt 5 and OS's for which we have confirmation the issue
exists.
It would be nice to not just list the bugs that switching to Qt 5
would bring, but also the fixes or elimination of workarounds that the
switch would bring.
The best is to open a tracking bug, and then a ticket for each
individual problem.
1) Q_WS_XXX macros are not defined. This would be easily solved
by replacing them with appropriate Q_OS_XXX macros.
2) QWindowsMime class not available. This only affects Windows and
results in not having vector graphics when pasting images. The
code is protected by Q_WS_WIN32 and does not get compiled in,
so the build succeeds anyway.
3) Shortcuts are always doubled when entered through the GUI. This
affects all platforms and I was not able to find the reason. The
only workaround I found is the attached hack which simply drops
any other keystroke.
There is a long discussion of this topic here:
Lyx-Devel Mailing list, Subject: LyX on OS X 10.9

http://comments.gmane.org/gmane.editors.lyx.devel/150265

Stephan
Enrico Forestieri
2014-07-16 10:40:34 UTC
Permalink
Post by Enrico Forestieri
1) Q_WS_XXX macros are not defined. This would be easily solved
by replacing them with appropriate Q_OS_XXX macros.
2) QWindowsMime class not available. This only affects Windows and
results in not having vector graphics when pasting images. The
code is protected by Q_WS_WIN32 and does not get compiled in,
so the build succeeds anyway.
3) Shortcuts are always doubled when entered through the GUI. This
affects all platforms and I was not able to find the reason. The
only workaround I found is the attached hack which simply drops
any other keystroke.
Actually, there is a fourth issue:

4) The autotools machinery need to be updated. Currently, I simply
patch the generated configure script to be able to compile with
Qt5.
--
Enrico
Enrico Forestieri
2014-07-16 22:49:40 UTC
Permalink
Post by Enrico Forestieri
4) The autotools machinery need to be updated. Currently, I simply
patch the generated configure script to be able to compile with
Qt5.
I attach here two patches that allow to build against Qt5 using autotools.
The first one (enable-qt5-minimal.diff) only touches qt4.m4, while the
second one (enable-qt5-full.diff) is functionally equivalent but also
renames all variables having qt4 or QT4 in their names. Thus, it also
touches the Makefile.am's and some script for Mac, but only to rename
the relevant variables.

The patch introduces the switch --enable-qt5 that allows to properly
configure LyX for using the Qt5 libraries. Without that switch, the
configure goes exactly as before (Qt4 is the default).

I plan to apply the patch if I get no objections.
--
Enrico
Enrico Forestieri
2014-07-16 22:51:00 UTC
Permalink
Post by Enrico Forestieri
Post by Enrico Forestieri
4) The autotools machinery need to be updated. Currently, I simply
patch the generated configure script to be able to compile with
Qt5.
I attach here two patches that allow to build against Qt5 using autotools.
The first one (enable-qt5-minimal.diff) only touches qt4.m4, while the
second one (enable-qt5-full.diff) is functionally equivalent but also
renames all variables having qt4 or QT4 in their names. Thus, it also
touches the Makefile.am's and some script for Mac, but only to rename
the relevant variables.
The patch introduces the switch --enable-qt5 that allows to properly
configure LyX for using the Qt5 libraries. Without that switch, the
configure goes exactly as before (Qt4 is the default).
I plan to apply the patch if I get no objections.
Now with the patches ;)
--
Enrico
Kornel Benko
2014-07-16 17:30:43 UTC
Permalink
Post by Enrico Forestieri
Post by Jean-Marc Lasgouttes
Post by Scott Kostyshak
It seems that switching to Qt 5 is still a bit away, but planning
early is always a good idea. I would like to start (if it exists
already, please let me know) either a wiki page or a trac issue
keeping track of issues that we think have to do with Qt 4 vs. Qt 5.
Hopefully for each issue related to LyX with Qt 5 we can list the
versions of Qt 5 and OS's for which we have confirmation the issue
exists.
It would be nice to not just list the bugs that switching to Qt 5
would bring, but also the fixes or elimination of workarounds that the
switch would bring.
The best is to open a tracking bug, and then a ticket for each
individual problem.
1) Q_WS_XXX macros are not defined. This would be easily solved
by replacing them with appropriate Q_OS_XXX macros.
2) QWindowsMime class not available. This only affects Windows and
results in not having vector graphics when pasting images. The
code is protected by Q_WS_WIN32 and does not get compiled in,
so the build succeeds anyway.
3) Shortcuts are always doubled when entered through the GUI. This
affects all platforms and I was not able to find the reason. The
only workaround I found is the attached hack which simply drops
any other keystroke.
I tried the attached patch, but it seams, shortcuts are not the only ones doubling key events.

Each tab creates this output (output by 'lyx -dbg key'), even with the patch.
(Noticed by Scott)

frontends/qt4/GuiWorkArea.cpp (1075): count: 1 text: isAutoRepeat: 0 key: 16777217 keyState:
frontends/qt4/GuiKeySymbol.cpp (623): Getting key 16777217, with text ' '
frontends/qt4/GuiKeySymbol.cpp (629): Setting key to 16777217,
frontends/qt4/GuiKeySymbol.cpp (644): isOK is 1
frontends/qt4/GuiApplication.cpp (2019): KeySym is Tab
frontends/qt4/GuiKeySymbol.cpp (644): isOK is 1
frontends/qt4/GuiKeySymbol.cpp (652): isModifier is 0
frontends/qt4/GuiApplication.cpp (2042): action first set to [command-alternatives]
frontends/qt4/GuiApplication.cpp (2050): action now set to [command-alternatives]
frontends/qt4/GuiApplication.cpp (2061): Key [action=command-alternatives][Tab]
frontends/qt4/GuiWorkArea.cpp (1075): count: 1 text: isAutoRepeat: 0 key: 16777217 keyState:
frontends/qt4/GuiKeySymbol.cpp (623): Getting key 16777217, with text ' '
frontends/qt4/GuiKeySymbol.cpp (629): Setting key to 16777217,
frontends/qt4/GuiKeySymbol.cpp (644): isOK is 1
frontends/qt4/GuiApplication.cpp (2019): KeySym is Tab
frontends/qt4/GuiKeySymbol.cpp (644): isOK is 1
frontends/qt4/GuiKeySymbol.cpp (652): isModifier is 0
frontends/qt4/GuiApplication.cpp (2042): action first set to [command-alternatives]
frontends/qt4/GuiApplication.cpp (2050): action now set to [command-alternatives]
frontends/qt4/GuiApplication.cpp (2061): Key [action=command-alternatives][Tab]

Kornel
Enrico Forestieri
2014-07-16 20:11:49 UTC
Permalink
This post might be inappropriate. Click to display it.
Enrico Forestieri
2014-07-16 20:57:55 UTC
Permalink
Post by Enrico Forestieri
Post by Kornel Benko
I tried the attached patch, but it seams, shortcuts are not the only ones
doubling key events.
Each tab creates this output (output by 'lyx -dbg key'), even with the patch.
(Noticed by Scott)
The patch was only addressing the shortcuts, so no surprise that it was
not working in this case. I had missed that also the tab key was being
doubled and cannot understand why.
It seems to be a known Qt5 "feature", related to ShortcutOverride events.
See https://bugreports.qt-project.org/browse/QTBUG-30164
--
Enrico
Enrico Forestieri
2014-07-16 21:28:48 UTC
Permalink
Post by Enrico Forestieri
It seems to be a known Qt5 "feature", related to ShortcutOverride events.
See https://bugreports.qt-project.org/browse/QTBUG-30164
Sorry, that bug was for Macs, here is the right one:
https://bugreports.qt-project.org/browse/QTBUG-38986
--
Enrico
Scott Kostyshak
2014-07-16 22:02:01 UTC
Permalink
Post by Enrico Forestieri
Post by Enrico Forestieri
It seems to be a known Qt5 "feature", related to ShortcutOverride events.
See https://bugreports.qt-project.org/browse/QTBUG-30164
https://bugreports.qt-project.org/browse/QTBUG-38986
Another key press issue is affecting our keytests. I've asked for help
on it here:
https://www.mail-archive.com/***@qt-project.org/msg12085.html
and just now posted on a bug report that I think might be related:
https://bugreports.qt-project.org/browse/QTBUG-7465

If anyone is interested in reproducing, build with CMake and run
ctest -R "hello"
Note that some dependencies might be needed for the keytests to be
enabled. Please ask if curious about details.

Scott
Enrico Forestieri
2014-07-16 22:10:14 UTC
Permalink
Post by Enrico Forestieri
Post by Enrico Forestieri
It seems to be a known Qt5 "feature", related to ShortcutOverride events.
See https://bugreports.qt-project.org/browse/QTBUG-30164
https://bugreports.qt-project.org/browse/QTBUG-38986
I have applied the patch mentioned there to the 5.3.0 sources and
recompiled libQt5Widgets. After replacing the shared library, the
problem with the tab key and the shortcuts disappeared. So, the
next release should fix this issue. I attach here the patch I used.
--
Enrico
Scott Kostyshak
2014-07-16 22:01:56 UTC
Permalink
On Wed, Jul 16, 2014 at 5:04 AM, Jean-Marc Lasgouttes
The best is to open a tracking bug, and then a ticket for each individual
problem.
OK I will do this (unless someone does it before I get to it).

Scott
Scott Kostyshak
2014-07-26 21:40:54 UTC
Permalink
Post by Scott Kostyshak
On Wed, Jul 16, 2014 at 5:04 AM, Jean-Marc Lasgouttes
The best is to open a tracking bug, and then a ticket for each individual
problem.
OK I will do this (unless someone does it before I get to it).
I've gone back through this thread and have the following pending
issues. Unless someone suggests otherwise or has edits or additions, I
will open an individual ticket (with no milestone I suppose) for each.
Let me know by Monday.

1) Q_WS_XXX macros are not defined. This would be easily solved by
replacing them with appropriate Q_OS_XXX macros.

2) QWindowsMime class not available. This only affects Windows and
results in not having vector graphics when pasting images. The code is
protected by Q_WS_WIN32 and does not get compiled in, so the build
succeeds anyway.

3) Shortcuts and tabs are always doubled when entered through the GUI.
This affects all platforms. See:
https://bugreports.qt-project.org/browse/QTBUG-38986 Enrico confirms
that the patch mentioned there combined with Qt 5.3.0 fixes the issue
in LyX with the tab and shortcuts.

4) The autotools machinery need to be updated. Currently, I simply
patch the generated configure script to be able to compile with Qt5.

5) keytests with Qt 5 do not work with capital letters I've asked for
help on it here:
https://www.mail-archive.com/***@qt-project.org/msg12085.html
and just now posted on a bug report that I think might be related:
https://bugreports.qt-project.org/browse/QTBUG-7465
If anyone is interested in reproducing, build with CMake and run
ctest -R "hello"
Note that some dependencies might be needed for the keytests to be
enabled. Please ask if curious about details.

Scott
Scott Kostyshak
2014-07-28 14:33:06 UTC
Permalink
Post by Scott Kostyshak
Post by Scott Kostyshak
On Wed, Jul 16, 2014 at 5:04 AM, Jean-Marc Lasgouttes
The best is to open a tracking bug, and then a ticket for each individual
problem.
OK I will do this (unless someone does it before I get to it).
I've gone back through this thread and have the following pending
issues. Unless someone suggests otherwise or has edits or additions, I
will open an individual ticket (with no milestone I suppose) for each.
Let me know by Monday.
The meta ticket is at 9215. Note that I did not select the component
"frontend-qt4", because I guess it's a "frontend-qt5" issue (see issue
#9221). I made them as enhancement requests because we do not
officially support Qt 5.

Scott

Loading...