Discussion:
QUESTION: How to enable Qt5 for LyX master
Stephan Witt
2014-08-25 13:53:14 UTC
Permalink
Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore.
The reasoning is to disable all platform specific code and force the Qt users
like us to review all code guarded by Q_WS_ macros. This means all code in LyX
inside these ifdef's is not compiled and executed anymore with Qt5.

My question now is: should we simply replace all Q_WS_ macros with the
corresponding Q_OS_ macro for all platforms or should this be done for every
platform in separate steps?

The first patch does this for all platforms - in case someone wants to test it too.
The second one is for Mac OS X only. I'll plan to commit the second one if I don't
get enough encouraging feedback for the first one.

With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6.

Stephan
Stephan Witt
2014-08-25 14:03:14 UTC
Permalink
Post by Stephan Witt
Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore.
The reasoning is to disable all platform specific code and force the Qt users
like us to review all code guarded by Q_WS_ macros. This means all code in LyX
inside these ifdef's is not compiled and executed anymore with Qt5.
My question now is: should we simply replace all Q_WS_ macros with the
corresponding Q_OS_ macro for all platforms or should this be done for every
platform in separate steps?
The first patch does this for all platforms - in case someone wants to test it too.
The second one is for Mac OS X only. I'll plan to commit the second one if I don't
get enough encouraging feedback for the first one.
With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6.
Stephan
<2014-08-25-Qt5-all-platforms.patch><2014-08-25-Qt5-mac-platform.patch>
Sorry for the noise regarding X11 - I see now Q_WS_X11 shouldn't be replaced.

Since only a limited count of lyx devs is able to compile and run windows
I'd guess I stick with the second patch - change it for Mac OS only.

Stephan
Kornel Benko
2014-08-25 14:08:27 UTC
Permalink
Post by Stephan Witt
Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore.
The reasoning is to disable all platform specific code and force the Qt users
like us to review all code guarded by Q_WS_ macros. This means all code in LyX
inside these ifdef's is not compiled and executed anymore with Qt5.
My question now is: should we simply replace all Q_WS_ macros with the
corresponding Q_OS_ macro for all platforms or should this be done for every
platform in separate steps?
The first patch does this for all platforms - in case someone wants to test it too.
The second one is for Mac OS X only. I'll plan to commit the second one if I don't
get enough encouraging feedback for the first one.
With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6.
Stephan
At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4 compilation.

Kornel
Kornel Benko
2014-08-25 14:12:17 UTC
Permalink
Post by Kornel Benko
Post by Stephan Witt
Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore.
The reasoning is to disable all platform specific code and force the Qt users
like us to review all code guarded by Q_WS_ macros. This means all code in LyX
inside these ifdef's is not compiled and executed anymore with Qt5.
My question now is: should we simply replace all Q_WS_ macros with the
corresponding Q_OS_ macro for all platforms or should this be done for every
platform in separate steps?
The first patch does this for all platforms - in case someone wants to test it too.
The second one is for Mac OS X only. I'll plan to commit the second one if I don't
get enough encouraging feedback for the first one.
With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6.
Stephan
At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4 compilation.
To be more specific

FindQt4.cmake:
We should check for Q_WS_X11, but assign variable Q_OS_X11.

Kornel
Stephan Witt
2014-08-25 14:18:02 UTC
Permalink
Post by Kornel Benko
Post by Kornel Benko
Post by Stephan Witt
Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore.
The reasoning is to disable all platform specific code and force the Qt users
like us to review all code guarded by Q_WS_ macros. This means all code in LyX
inside these ifdef's is not compiled and executed anymore with Qt5.
My question now is: should we simply replace all Q_WS_ macros with the
corresponding Q_OS_ macro for all platforms or should this be done for every
platform in separate steps?
The first patch does this for all platforms - in case someone wants to test it too.
The second one is for Mac OS X only. I'll plan to commit the second one if I don't
get enough encouraging feedback for the first one.
With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6.
Stephan
At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4 compilation.
To be more specific
We should check for Q_WS_X11, but assign variable Q_OS_X11.
Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within Qt5 either.

Stephan
Enrico Forestieri
2014-08-25 15:54:08 UTC
Permalink
Post by Stephan Witt
Post by Kornel Benko
Post by Kornel Benko
At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4
compilation.
To be more specific
We should check for Q_WS_X11, but assign variable Q_OS_X11.
Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within Qt5 either.
Not only that. Some of the Q_WS_WIN guards should not be replaced at all,
othewise it will not compile with Qt5. For example, the QWindowsMime class
is not available anymore and, until they make it available again, that
guard should not be replaced. So, I suggest to replace the guards only
if you are able to check the result.

Another side effect is that my Qt5 port for cygwin will require its own
guard now that Q_WS_WIN is not available anymore. I wonder what they were
drinking when that decision was taken...
--
Enrico
Stephan Witt
2014-08-25 17:56:08 UTC
Permalink
Post by Enrico Forestieri
Post by Stephan Witt
Post by Kornel Benko
Post by Kornel Benko
At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4
compilation.
To be more specific
We should check for Q_WS_X11, but assign variable Q_OS_X11.
Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within Qt5 either.
Not only that. Some of the Q_WS_WIN guards should not be replaced at all,
othewise it will not compile with Qt5. For example, the QWindowsMime class
is not available anymore and, until they make it available again, that
guard should not be replaced. So, I suggest to replace the guards only
if you are able to check the result.
Ok, I'll do it then this way. Thanks.
Post by Enrico Forestieri
Another side effect is that my Qt5 port for cygwin will require its own
guard now that Q_WS_WIN is not available anymore. I wonder what they were
drinking when that decision was taken…
+1

Stephan
Post by Enrico Forestieri
--
Enrico
Enrico Forestieri
2014-08-25 17:58:20 UTC
Permalink
Post by Enrico Forestieri
Post by Stephan Witt
Post by Kornel Benko
Post by Kornel Benko
At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4
compilation.
To be more specific
We should check for Q_WS_X11, but assign variable Q_OS_X11.
Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within Qt5 either.
Not only that. Some of the Q_WS_WIN guards should not be replaced at all,
othewise it will not compile with Qt5. For example, the QWindowsMime class
is not available anymore and, until they make it available again, that
guard should not be replaced. So, I suggest to replace the guards only
if you are able to check the result.
Another side effect is that my Qt5 port for cygwin will require its own
guard now that Q_WS_WIN is not available anymore. I wonder what they were
drinking when that decision was taken...
I went ahead and replaced almost all occurrences of Q_WS_WIN as appropriate
for Qt5. The remaining ones are those related to code that doesn't compile
on Qt5, ATM.
--
Enrico
Stephan Witt
2014-08-25 18:11:07 UTC
Permalink
Post by Enrico Forestieri
Post by Enrico Forestieri
Post by Stephan Witt
Post by Kornel Benko
Post by Kornel Benko
At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4
compilation.
To be more specific
We should check for Q_WS_X11, but assign variable Q_OS_X11.
Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within Qt5 either.
Not only that. Some of the Q_WS_WIN guards should not be replaced at all,
othewise it will not compile with Qt5. For example, the QWindowsMime class
is not available anymore and, until they make it available again, that
guard should not be replaced. So, I suggest to replace the guards only
if you are able to check the result.
Another side effect is that my Qt5 port for cygwin will require its own
guard now that Q_WS_WIN is not available anymore. I wonder what they were
drinking when that decision was taken...
I went ahead and replaced almost all occurrences of Q_WS_WIN as appropriate
for Qt5. The remaining ones are those related to code that doesn't compile
on Qt5, ATM.
Ok, I did it for Q_WS_MACX now.

Stephan

Loading...