Re: LyX+Qt5 build (CMake+XCode) on OS X
Sent from my iPad > On 25 Aug 2014, at 07:55, Stephan Witt wrote: > >> Am 23.08.2014 um 18:01 schrieb Patrick De Visschere : >> >>> On 23 Aug, 2014, at 14:50 , Stephan Witt wrote: >>> Am 23.08.2014 um 12:01 schrieb Patrick De Visschere : > On 20 Aug, 2014, at 23:15 , Stephan Witt wrote: > >> Am 20.08.2014 um 22:45 schrieb Patrick De Visschere >> : >> >>> On 20 Aug, 2014, at 11:22 , Stephan Witt wrote: >>> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere : > On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: > > Am 17.08.2014 um 20:13 schrieb Patrick De Visschere > : My environment * Mac OS X 10.9.4 * Darwin Kernel Version 13.3.0 * Qt 5.3.1 (stable branch) (default Cocoa) ./configure -opensource -silent -shared -release -no-dbus -nomake examples -nomake tools -no-framework >>> >>> You don't build the libraries as frameworks. I'm not sure if this makes >>> no difference. >>> >>> I'm using the Qt frameworks I've build myself. >>> >>> Stephan >> >> Stephan, >> >> I was planning to do that. (the qt-debug build does not make a >> difference as you expected) >> >> I suppose you use the LyX-Mac-binary-release.sh script. >> >> I have never managed to use this script without making changes to it, >> perhaps because I’m using it the wrong way. >> >> I build qt as a framework separately and would then use the script like: >> >> sh development/LyX-Mac-binary-release.sh --with-qt-frameworks=yes >> --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 >> --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 >> --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug >> >> I think the --with-qt-frameworks=yes is needed to include qt as a >> framework; >> >> and --with-qt-dir=/… points to the dir where the qt-framework has been >> installed (previously). >> >> I’m not sure about the exact meaning of --qt-deployment=yes but I think >> I need it too. >> >> What I don’t understand are the lines 260-262 >> if [ "${configure_qt_frameworks}" != "yes" ]; then >>QtInstallDir=${QTDIR:-"/opt/qt4"} >> fi >> >> with --with-qt-frameworks=yes, QtInstallDir is not set. >> >> Therefore I uncomment the if/fi so that >> QtInstallDir=${QTDIR:-"/opt/qt4”} >> >> is always executed and QtInstallDir points to my qt-install dir. >> >> In addition I must modify some CPPFLAGS= ... >> >> Any idea what I’m doing wrong? >> >> Patrick De Visschere > > Perhaps I should remove the --with-qt-frameworks switch. I don't use it > anymore > and it was meant as "with the frameworks by Qt (Nokia)". The > --qt-deployment=yes > is default and with it the script copies the frameworks to the package. > This is > needed if you want to use the LyX app on another system. > > I'd avoid the --with-libiconv-prefix=/opt/local switch. > > This is the shell script I'm using for calling LyX-Mac-binary-release.sh: > > #!/bin/sh > ARCH=x86_64 > QtVersion=5.3.1 > QtAPI=-cocoa > LyXVersion=lyx > CC=cc CXX=c++ \ > QtConfigureOptions="-debug-and-release" QtAPI=${QtAPI} > QtVersion=${QtVersion} \ > sh ${MKFLAGS} ${LyXVersion}/development/LyX-Mac-binary-release.sh \ > --with-sdkroot=10.8 --with-macosx-target=10.6 --with-arch=${ARCH} \ > --with-qt-dir=/Users/Shared/LyX/qt-${QtVersion}-frameworks${QtAPI}-${ARCH} > \ > "$@" > > Stephan I’ve build LyX+Qt5 with the LyX-Mac-binary-release.sh script and the menubar appears immediately. Since with XCode I use the macports iconv library that could still theoretically be the culprit. Or maybe it’s just due to Xcode. Anyway this is not very important; I tried to build (with Xcode) without aspell and hunspell but somehow cmake doesn’t want that. >>> >>> This is my script to call cmake for Xcode project generation: >>> >>> #!/bin/sh >>> export PATH="/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64/bin:${PATH}" >>> LyxSourceDir="$(pwd)/lyx" >>> LyxUtilDir="/Users/Shared/LyX/utilities" >>> CMAKE_GENERATOR="Xcode" >>> LyXVersion=$(grep AC_INIT "${LyxSourceDir}"/configure.ac | cut -d, -f2 | tr >>> -d " ()") >>> LyxBuildDir=lyx-build/cmake/"${LyXVersion}" >>> if [ -f "${LyxSourceDir}/development/cmake/CMakeLists.txt" ]; then >>> TOPCMAKE="${LyxSourceDir}/development/cmake" >>> COPYRESOURCES="yes" >>> else >>> TOPCMAKE="${LyxSourceDir}" >>> fi >>> rm -rf "${LyxBuildDir}" >>> mkdir -p "${LyxBuildDir}" >>> >>> case "$(qmake -version)" in >>> *Using*5.*) >>> LYX_USE_QT="-DLYX_USE_QT=QT5" >>> esac >>> >>> SPELLER_OPTIONS="-DASPEL
Re: LyX+Qt5 build (CMake+XCode) on OS X
Am 23.08.2014 um 18:01 schrieb Patrick De Visschere : > On 23 Aug, 2014, at 14:50 , Stephan Witt wrote: > >> Am 23.08.2014 um 12:01 schrieb Patrick De Visschere : >> >>> On 20 Aug, 2014, at 23:15 , Stephan Witt wrote: >>> Am 20.08.2014 um 22:45 schrieb Patrick De Visschere : > On 20 Aug, 2014, at 11:22 , Stephan Witt wrote: > >> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere >> : >> >>> On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: >>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere : >>> >>> My environment >>> >>> * Mac OS X 10.9.4 >>> * Darwin Kernel Version 13.3.0 >>> * Qt 5.3.1 (stable branch) (default Cocoa) >>> ./configure -opensource -silent -shared -release -no-dbus -nomake >>> examples -nomake tools -no-framework >> >> You don't build the libraries as frameworks. I'm not sure if this makes >> no difference. >> >> I'm using the Qt frameworks I've build myself. >> >> Stephan > > Stephan, > > I was planning to do that. (the qt-debug build does not make a difference > as you expected) > > I suppose you use the LyX-Mac-binary-release.sh script. > > I have never managed to use this script without making changes to it, > perhaps because I’m using it the wrong way. > > I build qt as a framework separately and would then use the script like: > > sh development/LyX-Mac-binary-release.sh --with-qt-frameworks=yes > --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 > --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 > --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug > > I think the --with-qt-frameworks=yes is needed to include qt as a > framework; > > and --with-qt-dir=/… points to the dir where the qt-framework has been > installed (previously). > > I’m not sure about the exact meaning of --qt-deployment=yes but I think > I need it too. > > What I don’t understand are the lines 260-262 > if [ "${configure_qt_frameworks}" != "yes" ]; then > QtInstallDir=${QTDIR:-"/opt/qt4"} > fi > > with --with-qt-frameworks=yes, QtInstallDir is not set. > > Therefore I uncomment the if/fi so that > QtInstallDir=${QTDIR:-"/opt/qt4”} > > is always executed and QtInstallDir points to my qt-install dir. > > In addition I must modify some CPPFLAGS= ... > > Any idea what I’m doing wrong? > > Patrick De Visschere Perhaps I should remove the --with-qt-frameworks switch. I don't use it anymore and it was meant as "with the frameworks by Qt (Nokia)". The --qt-deployment=yes is default and with it the script copies the frameworks to the package. This is needed if you want to use the LyX app on another system. I'd avoid the --with-libiconv-prefix=/opt/local switch. This is the shell script I'm using for calling LyX-Mac-binary-release.sh: #!/bin/sh ARCH=x86_64 QtVersion=5.3.1 QtAPI=-cocoa LyXVersion=lyx CC=cc CXX=c++ \ QtConfigureOptions="-debug-and-release" QtAPI=${QtAPI} QtVersion=${QtVersion} \ sh ${MKFLAGS} ${LyXVersion}/development/LyX-Mac-binary-release.sh \ --with-sdkroot=10.8 --with-macosx-target=10.6 --with-arch=${ARCH} \ --with-qt-dir=/Users/Shared/LyX/qt-${QtVersion}-frameworks${QtAPI}-${ARCH} \ "$@" Stephan >>> >>> I’ve build LyX+Qt5 with the LyX-Mac-binary-release.sh script and the >>> menubar appears immediately. Since with XCode I use the macports iconv >>> library that could still theoretically be the culprit. Or maybe it’s just >>> due to Xcode. Anyway this is not very important; >>> I tried to build (with Xcode) without aspell and hunspell but somehow cmake >>> doesn’t want that. >> >> This is my script to call cmake for Xcode project generation: >> >> #!/bin/sh >> export PATH="/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64/bin:${PATH}" >> LyxSourceDir="$(pwd)/lyx" >> LyxUtilDir="/Users/Shared/LyX/utilities" >> CMAKE_GENERATOR="Xcode" >> LyXVersion=$(grep AC_INIT "${LyxSourceDir}"/configure.ac | cut -d, -f2 | tr >> -d " ()") >> LyxBuildDir=lyx-build/cmake/"${LyXVersion}" >> if [ -f "${LyxSourceDir}/development/cmake/CMakeLists.txt" ]; then >> TOPCMAKE="${LyxSourceDir}/development/cmake" >> COPYRESOURCES="yes" >> else >> TOPCMAKE="${LyxSourceDir}" >> fi >> rm -rf "${LyxBuildDir}" >> mkdir -p "${LyxBuildDir}" >> >> case "$(qmake -version)" in >> *Using*5.*) >> LYX_USE_QT="-DLYX_USE_QT=QT5" >> esac >> >> SPELLER_OPTIONS="-DASPELL_INCLUDE_DIR=${LyxUtilDir}/include \ >> -DASPELL_LIBRARY_RELEASE=${LyxUtilDir}/lib/libaspell.dylib \ >> -DHUNSPELL_INCLUDE_DIR=${LyxUtilDir}/include \ >> -DHUNSPELL_LIBRARY=${LyxUtilDir}/lib/libhunspell.dylib \ >> -DMagic_INCLUDE_D
Re: LyX+Qt5 build (CMake+XCode) on OS X
On 23 Aug, 2014, at 14:50 , Stephan Witt wrote: > Am 23.08.2014 um 12:01 schrieb Patrick De Visschere : > >> On 20 Aug, 2014, at 23:15 , Stephan Witt wrote: >> >>> Am 20.08.2014 um 22:45 schrieb Patrick De Visschere : >>> On 20 Aug, 2014, at 11:22 , Stephan Witt wrote: > Am 19.08.2014 um 22:41 schrieb Patrick De Visschere > : > >> On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: >> >>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere >>> : >> >> My environment >> >> * Mac OS X 10.9.4 >> * Darwin Kernel Version 13.3.0 >> * Qt 5.3.1 (stable branch) (default Cocoa) >> ./configure -opensource -silent -shared -release -no-dbus -nomake >> examples -nomake tools -no-framework > > You don't build the libraries as frameworks. I'm not sure if this makes > no difference. > > I'm using the Qt frameworks I've build myself. > > Stephan Stephan, I was planning to do that. (the qt-debug build does not make a difference as you expected) I suppose you use the LyX-Mac-binary-release.sh script. I have never managed to use this script without making changes to it, perhaps because I’m using it the wrong way. I build qt as a framework separately and would then use the script like: sh development/LyX-Mac-binary-release.sh --with-qt-frameworks=yes --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug I think the --with-qt-frameworks=yes is needed to include qt as a framework; and --with-qt-dir=/… points to the dir where the qt-framework has been installed (previously). I’m not sure about the exact meaning of --qt-deployment=yes but I think I need it too. What I don’t understand are the lines 260-262 if [ "${configure_qt_frameworks}" != "yes" ]; then QtInstallDir=${QTDIR:-"/opt/qt4"} fi with --with-qt-frameworks=yes, QtInstallDir is not set. Therefore I uncomment the if/fi so that QtInstallDir=${QTDIR:-"/opt/qt4”} is always executed and QtInstallDir points to my qt-install dir. In addition I must modify some CPPFLAGS= ... Any idea what I’m doing wrong? Patrick De Visschere >>> >>> Perhaps I should remove the --with-qt-frameworks switch. I don't use it >>> anymore >>> and it was meant as "with the frameworks by Qt (Nokia)". The >>> --qt-deployment=yes >>> is default and with it the script copies the frameworks to the package. >>> This is >>> needed if you want to use the LyX app on another system. >>> >>> I'd avoid the --with-libiconv-prefix=/opt/local switch. >>> >>> This is the shell script I'm using for calling LyX-Mac-binary-release.sh: >>> >>> #!/bin/sh >>> ARCH=x86_64 >>> QtVersion=5.3.1 >>> QtAPI=-cocoa >>> LyXVersion=lyx >>> CC=cc CXX=c++ \ >>> QtConfigureOptions="-debug-and-release" QtAPI=${QtAPI} >>> QtVersion=${QtVersion} \ >>> sh ${MKFLAGS} ${LyXVersion}/development/LyX-Mac-binary-release.sh \ >>> --with-sdkroot=10.8 --with-macosx-target=10.6 --with-arch=${ARCH} \ >>> --with-qt-dir=/Users/Shared/LyX/qt-${QtVersion}-frameworks${QtAPI}-${ARCH} >>> \ >>> "$@" >>> >>> Stephan >> >> I’ve build LyX+Qt5 with the LyX-Mac-binary-release.sh script and the menubar >> appears immediately. Since with XCode I use the macports iconv library that >> could still theoretically be the culprit. Or maybe it’s just due to Xcode. >> Anyway this is not very important; >> I tried to build (with Xcode) without aspell and hunspell but somehow cmake >> doesn’t want that. > > This is my script to call cmake for Xcode project generation: > > #!/bin/sh > export PATH="/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64/bin:${PATH}" > LyxSourceDir="$(pwd)/lyx" > LyxUtilDir="/Users/Shared/LyX/utilities" > CMAKE_GENERATOR="Xcode" > LyXVersion=$(grep AC_INIT "${LyxSourceDir}"/configure.ac | cut -d, -f2 | tr > -d " ()") > LyxBuildDir=lyx-build/cmake/"${LyXVersion}" > if [ -f "${LyxSourceDir}/development/cmake/CMakeLists.txt" ]; then > TOPCMAKE="${LyxSourceDir}/development/cmake" > COPYRESOURCES="yes" > else > TOPCMAKE="${LyxSourceDir}" > fi > rm -rf "${LyxBuildDir}" > mkdir -p "${LyxBuildDir}" > > case "$(qmake -version)" in > *Using*5.*) > LYX_USE_QT="-DLYX_USE_QT=QT5" > esac > > SPELLER_OPTIONS="-DASPELL_INCLUDE_DIR=${LyxUtilDir}/include \ > -DASPELL_LIBRARY_RELEASE=${LyxUtilDir}/lib/libaspell.dylib \ > -DHUNSPELL_INCLUDE_DIR=${LyxUtilDir}/include \ > -DHUNSPELL_LIBRARY=${LyxUtilDir}/lib/libhunspell.dylib \ > -DMagic_INCLUDE_DIR=${LyxUtilDir}/include \ > -DMagic_LIBRARY=${LyxUtilDir}/lib/libmagic.dylib \ > -DLYX_ASPELL=ON -DLYX_HUNSPELL=ON" > ( > cd "${LyxBuildDir}" && \ > cmake -G "${CMAKE_GENERATOR}" "${
Re: LyX+Qt5 build (CMake+XCode) on OS X
Am 23.08.2014 um 12:01 schrieb Patrick De Visschere : > On 20 Aug, 2014, at 23:15 , Stephan Witt wrote: > >> Am 20.08.2014 um 22:45 schrieb Patrick De Visschere : >> >>> On 20 Aug, 2014, at 11:22 , Stephan Witt wrote: >>> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere : > On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: > >> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere >> : > > My environment > > * Mac OS X 10.9.4 > * Darwin Kernel Version 13.3.0 > * Qt 5.3.1 (stable branch) (default Cocoa) > ./configure -opensource -silent -shared -release -no-dbus -nomake > examples -nomake tools -no-framework You don't build the libraries as frameworks. I'm not sure if this makes no difference. I'm using the Qt frameworks I've build myself. Stephan >>> >>> Stephan, >>> >>> I was planning to do that. (the qt-debug build does not make a difference >>> as you expected) >>> >>> I suppose you use the LyX-Mac-binary-release.sh script. >>> >>> I have never managed to use this script without making changes to it, >>> perhaps because I’m using it the wrong way. >>> >>> I build qt as a framework separately and would then use the script like: >>> >>> sh development/LyX-Mac-binary-release.sh --with-qt-frameworks=yes >>> --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 >>> --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 >>> --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug >>> >>> I think the --with-qt-frameworks=yes is needed to include qt as a framework; >>> >>> and --with-qt-dir=/… points to the dir where the qt-framework has been >>> installed (previously). >>> >>> I’m not sure about the exact meaning of --qt-deployment=yes but I think I >>> need it too. >>> >>> What I don’t understand are the lines 260-262 >>> if [ "${configure_qt_frameworks}" != "yes" ]; then >>> QtInstallDir=${QTDIR:-"/opt/qt4"} >>> fi >>> >>> with --with-qt-frameworks=yes, QtInstallDir is not set. >>> >>> Therefore I uncomment the if/fi so that >>> QtInstallDir=${QTDIR:-"/opt/qt4”} >>> >>> is always executed and QtInstallDir points to my qt-install dir. >>> >>> In addition I must modify some CPPFLAGS= ... >>> >>> Any idea what I’m doing wrong? >>> >>> Patrick De Visschere >> >> Perhaps I should remove the --with-qt-frameworks switch. I don't use it >> anymore >> and it was meant as "with the frameworks by Qt (Nokia)". The >> --qt-deployment=yes >> is default and with it the script copies the frameworks to the package. This >> is >> needed if you want to use the LyX app on another system. >> >> I'd avoid the --with-libiconv-prefix=/opt/local switch. >> >> This is the shell script I'm using for calling LyX-Mac-binary-release.sh: >> >> #!/bin/sh >> ARCH=x86_64 >> QtVersion=5.3.1 >> QtAPI=-cocoa >> LyXVersion=lyx >> CC=cc CXX=c++ \ >> QtConfigureOptions="-debug-and-release" QtAPI=${QtAPI} >> QtVersion=${QtVersion} \ >> sh ${MKFLAGS} ${LyXVersion}/development/LyX-Mac-binary-release.sh \ >> --with-sdkroot=10.8 --with-macosx-target=10.6 --with-arch=${ARCH} \ >> --with-qt-dir=/Users/Shared/LyX/qt-${QtVersion}-frameworks${QtAPI}-${ARCH} >> \ >> "$@" >> >> Stephan > > I’ve build LyX+Qt5 with the LyX-Mac-binary-release.sh script and the menubar > appears immediately. Since with XCode I use the macports iconv library that > could still theoretically be the culprit. Or maybe it’s just due to Xcode. > Anyway this is not very important; > I tried to build (with Xcode) without aspell and hunspell but somehow cmake > doesn’t want that. This is my script to call cmake for Xcode project generation: #!/bin/sh export PATH="/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64/bin:${PATH}" LyxSourceDir="$(pwd)/lyx" LyxUtilDir="/Users/Shared/LyX/utilities" CMAKE_GENERATOR="Xcode" LyXVersion=$(grep AC_INIT "${LyxSourceDir}"/configure.ac | cut -d, -f2 | tr -d " ()") LyxBuildDir=lyx-build/cmake/"${LyXVersion}" if [ -f "${LyxSourceDir}/development/cmake/CMakeLists.txt" ]; then TOPCMAKE="${LyxSourceDir}/development/cmake" COPYRESOURCES="yes" else TOPCMAKE="${LyxSourceDir}" fi rm -rf "${LyxBuildDir}" mkdir -p "${LyxBuildDir}" case "$(qmake -version)" in *Using*5.*) LYX_USE_QT="-DLYX_USE_QT=QT5" esac SPELLER_OPTIONS="-DASPELL_INCLUDE_DIR=${LyxUtilDir}/include \ -DASPELL_LIBRARY_RELEASE=${LyxUtilDir}/lib/libaspell.dylib \ -DHUNSPELL_INCLUDE_DIR=${LyxUtilDir}/include \ -DHUNSPELL_LIBRARY=${LyxUtilDir}/lib/libhunspell.dylib \ -DMagic_INCLUDE_DIR=${LyxUtilDir}/include \ -DMagic_LIBRARY=${LyxUtilDir}/lib/libmagic.dylib \ -DLYX_ASPELL=ON -DLYX_HUNSPELL=ON" ( cd "${LyxBuildDir}" && \ cmake -G "${CMAKE_GENERATOR}" "${TOPCMAKE}" \ -DLYX_NLS=OFF \ -DLYX_DEVEL_VERSION=ON -DLYX_DEBUG=ON -DLYX_RELEASE=OFF \ -DLYX_DEBUG_GLIBC=OFF -DLYX_DEBUG_GLIBC_PEDANTIC=OFF \ -DLYX_PACKAGE_SUFFIX=OFF -DLYX_PROGRAM_SUFFIX=OFF \
Re: LyX+Qt5 build (CMake+XCode) on OS X
On 20 Aug, 2014, at 23:15 , Stephan Witt wrote: > Am 20.08.2014 um 22:45 schrieb Patrick De Visschere : > >> On 20 Aug, 2014, at 11:22 , Stephan Witt wrote: >> >>> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere : >>> On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: > Am 17.08.2014 um 20:13 schrieb Patrick De Visschere > : My environment * Mac OS X 10.9.4 * Darwin Kernel Version 13.3.0 * Qt 5.3.1 (stable branch) (default Cocoa) ./configure -opensource -silent -shared -release -no-dbus -nomake examples -nomake tools -no-framework >>> >>> You don't build the libraries as frameworks. I'm not sure if this makes no >>> difference. >>> >>> I'm using the Qt frameworks I've build myself. >>> >>> Stephan >> >> Stephan, >> >> I was planning to do that. (the qt-debug build does not make a difference as >> you expected) >> >> I suppose you use the LyX-Mac-binary-release.sh script. >> >> I have never managed to use this script without making changes to it, >> perhaps because I’m using it the wrong way. >> >> I build qt as a framework separately and would then use the script like: >> >> sh development/LyX-Mac-binary-release.sh --with-qt-frameworks=yes >> --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 >> --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 >> --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug >> >> I think the --with-qt-frameworks=yes is needed to include qt as a framework; >> >> and --with-qt-dir=/… points to the dir where the qt-framework has been >> installed (previously). >> >> I’m not sure about the exact meaning of --qt-deployment=yes but I think I >> need it too. >> >> What I don’t understand are the lines 260-262 >> if [ "${configure_qt_frameworks}" != "yes" ]; then >> QtInstallDir=${QTDIR:-"/opt/qt4"} >> fi >> >> with --with-qt-frameworks=yes, QtInstallDir is not set. >> >> Therefore I uncomment the if/fi so that >> QtInstallDir=${QTDIR:-"/opt/qt4”} >> >> is always executed and QtInstallDir points to my qt-install dir. >> >> In addition I must modify some CPPFLAGS= ... >> >> Any idea what I’m doing wrong? >> >> Patrick De Visschere > > Perhaps I should remove the --with-qt-frameworks switch. I don't use it > anymore > and it was meant as "with the frameworks by Qt (Nokia)". The > --qt-deployment=yes > is default and with it the script copies the frameworks to the package. This > is > needed if you want to use the LyX app on another system. > > I'd avoid the --with-libiconv-prefix=/opt/local switch. > > This is the shell script I'm using for calling LyX-Mac-binary-release.sh: > > #!/bin/sh > ARCH=x86_64 > QtVersion=5.3.1 > QtAPI=-cocoa > LyXVersion=lyx > CC=cc CXX=c++ \ > QtConfigureOptions="-debug-and-release" QtAPI=${QtAPI} QtVersion=${QtVersion} > \ > sh ${MKFLAGS} ${LyXVersion}/development/LyX-Mac-binary-release.sh \ > --with-sdkroot=10.8 --with-macosx-target=10.6 --with-arch=${ARCH} \ > --with-qt-dir=/Users/Shared/LyX/qt-${QtVersion}-frameworks${QtAPI}-${ARCH} \ > "$@" > > Stephan I’ve build LyX+Qt5 with the LyX-Mac-binary-release.sh script and the menubar appears immediately. Since with XCode I use the macports iconv library that could still theoretically be the culprit. Or maybe it’s just due to Xcode. Anyway this is not very important; I tried to build (with Xcode) without aspell and hunspell but somehow cmake doesn’t want that. There were/are still some problems (with the manual build): 1) Aspell as it is fails to build (on 10.9 I assume). This is easily solved by applying the small patch used by macports. 2) I don’t understand how the lyx-build is supposed to find the Qt5-frameworks; Apparently the switches --enable-qt5 --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 are not sufficient. As before I changed the FLAGS in the script as follows (this is around line 610 of the script) if [ "$configure_qt_frameworks" = "yes" ]; then export QT_CORE_CFLAGS="-FQtCore" export QT_CORE_LIBS="-framework QtCore" export QT_FRONTEND_CFLAGS="-FQtGui" export QT_FRONTEND_LIBS="-framework QtGui" CPPFLAGS="${CPPFLAGS} -I${SDKROOT}/Library/Frameworks/QtCore.framework/Headers" CPPFLAGS="${CPPFLAGS} -I${SDKROOT}/Library/Frameworks/QtGui.framework/Headers" else CPPFLAGS="${CPPFLAGS} -I${QtInstallDir}/lib/QtCore.framework/Headers" CPPFLAGS="${CPPFLAGS} -I${QtInstallDir}/lib/QtGui.framework/Headers" CPPFLAGS="${CPPFLAGS} -I${QtInstallDir}/lib/QtWidgets.framework/Headers" CPPFLAGS="${CPPFLAGS} -I${QtInstallDir}/lib/QtMacExtras.framework/Headers" CPPFLAGS="${CPPFLAGS} -I${QtInstallDir}/lib/QtConcurrent.framework/Headers"
Re: LyX+Qt5 build (CMake+XCode) on OS X
Am 15.08.2014 um 13:57 schrieb Stephan Witt : > Am 12.08.2014 um 22:07 schrieb pdv : > >> As a follow-up on reports in the thread "LyX on OS X 10.9" from some months >> ago, I build LyX(master) + Qt5(stable) (CMake + XCode). >> >> I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle and >> observed then (at least) 2 issues: >> >> 1) When starting up the menu bar is not visible; One must switch to another >> app and then bring lyx to the foreground to make the menu bar appear. >> 2) When closing the (last) window the menu bar disappears mostly, except for >> the LyX menu. This was also reported by Stephan Witt, but I did observe no >> crash. >> >> When closing the last window Qt5 should switch to the "default menu bar" but >> apparently it doesn't find one and creates it's own minimal default menu bar. >> The default menu bar is created by GlobalMenuBar() (in GuiApplication.cpp) >> which has a constructor GlobalMenuBar() : new QMenuBar(0); according to the >> Qt docs the first parent-less QMenuBar created will be used as the default >> menu bar. Apparently Qt5 does not detect the QMenuBar(0) created via a >> subclass; >> >> When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is >> solved. >> >> GlobalMenuBar() was introduced to override the event() function to handle >> QEvent::ShortcutOverride events but shortcuts seem to work without using the >> GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only work >> after first activating one of them via the menu, but the latter also happens >> in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 confirms >> that GlobalMenuBar's event() is not called when issuing a shortcut with no >> window present. I assume that these standard mac-shortcuts are handled >> automatically by Qt. >> >> If someone wants to check this, see the attached patch, which includes all >> changes (but does not solve issue 1)). >> >> Patrick De Visschere >> > > Hi Patrick, > > the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a while > with the Qt5 build and failed to solve this issue 2. This I did while being > on vacation, so I couldn't answer earlier. > > The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by Qt5 > not showing a menu top item without any action attached. The latest change is > the dummy action has to be attached to the sub menu after the > addMenu(subMenu) method call. > > Both issues are regressions of Qt5, IMO. > > The QMacStyle doesn't need to be replaced if LyX is linked with the > QMacExtras framework. This was nonsense, sorry. And I confused it with things like QMacPasteboardMime from the QMacExtras framework. The opposite is true. QMacStyle can be replaced by QProxyStyle since Qt 4.6 and is not available anymore since 5.0. They made it an internal class one cannot access anymore. So, I think QProxyStyle can be used instead of QMacStyle unconditionally (for Qt4 too). Stephan
Re: LyX+Qt5 build (CMake+XCode) on OS X
Am 20.08.2014 um 23:31 schrieb Patrick De Visschere : > On 20 Aug, 2014, at 22:40 , Stephan Witt wrote: > >> Am 20.08.2014 um 20:46 schrieb Patrick De Visschere : >> >>> On 20 Aug, 2014, at 08:40 , Stephan Witt wrote: >>> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere : > On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: > >> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere >> : >> >>> On 15 Aug, 2014, at 13:57 , Stephan Witt wrote: >>> Am 12.08.2014 um 22:07 schrieb pdv : > As a follow-up on reports in the thread "LyX on OS X 10.9" from some > months ago, I build LyX(master) + Qt5(stable) (CMake + XCode). > > I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by > QProxyStyle and observed then (at least) 2 issues: > > 1) When starting up the menu bar is not visible; One must switch to > another app and then bring lyx to the foreground to make the menu bar > appear. > 2) When closing the (last) window the menu bar disappears mostly, > except for the LyX menu. This was also reported by Stephan Witt, but > I did observe no crash. > > When closing the last window Qt5 should switch to the "default menu > bar" but apparently it doesn't find one and creates it's own minimal > default menu bar. > The default menu bar is created by GlobalMenuBar() (in > GuiApplication.cpp) which has a constructor GlobalMenuBar() : new > QMenuBar(0); according to the Qt docs the first parent-less QMenuBar > created will be used as the default menu bar. Apparently Qt5 does not > detect the QMenuBar(0) created via a subclass; > > When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) > is solved. > > GlobalMenuBar() was introduced to override the event() function to > handle QEvent::ShortcutOverride events but shortcuts seem to work > without using the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; > Cmd-N and Cmd-O only work after first activating one of them via the > menu, but the latter also happens in LyX211 and may not be related to > Qt5). Building LyX + Qt4.8.6 confirms that GlobalMenuBar's event() is > not called when issuing a shortcut with no window present. I assume > that these standard mac-shortcuts are handled automatically by Qt. > > If someone wants to check this, see the attached patch, which > includes all changes (but does not solve issue 1)). > > Patrick De Visschere > Hi Patrick, the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a while with the Qt5 build and failed to solve this issue 2. This I did while being on vacation, so I couldn't answer earlier. The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by Qt5 not showing a menu top item without any action attached. The latest change is the dummy action has to be attached to the sub menu after the addMenu(subMenu) method call. >>> >>> I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does >>> include this dummy action, if I’m not mistaken. >> >> Yes, me too. But this dummy action is added before the addMenu(menu) >> method call. I've had to move it the addAction call after the addMenu >> call. >> Both issues are regressions of Qt5, IMO. The QMacStyle doesn't need to be replaced if LyX is linked with the QMacExtras framework. Regarding the Q_WS_MACX macro replacement I'm not sure what should be done. 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is available since 4.6.x at least. 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and Q_OS_WIN at the same time but cannot test all platforms. This results in the attached patch. It contains some additional changes in Menu.cpp I introduced while attacking the issue 2. Furthermore I changed CMakeLists.txt because of some warnings from newer cmake. This patch should not be commit as is but in some separate steps. Please, if someone can try it or comment on it, I'd like to hear other opinions. >>> >>> With this patch I get basically the same behaviour as I described in my >>> initial message. Without a window being present, Cmd-O and Cmd-N don’t >>> work right away. And the application still starts without the menubar >>> being visible (issue 1), but the shortcuts do work. >> >> Ok, that's not good. >> >> But on m
Re: LyX+Qt5 build (CMake+XCode) on OS X
On 20 Aug, 2014, at 22:40 , Stephan Witt wrote: > Am 20.08.2014 um 20:46 schrieb Patrick De Visschere : > >> On 20 Aug, 2014, at 08:40 , Stephan Witt wrote: >> >>> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere : >>> On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: > Am 17.08.2014 um 20:13 schrieb Patrick De Visschere > : > >> On 15 Aug, 2014, at 13:57 , Stephan Witt wrote: >> >>> Am 12.08.2014 um 22:07 schrieb pdv : >>> As a follow-up on reports in the thread "LyX on OS X 10.9" from some months ago, I build LyX(master) + Qt5(stable) (CMake + XCode). I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle and observed then (at least) 2 issues: 1) When starting up the menu bar is not visible; One must switch to another app and then bring lyx to the foreground to make the menu bar appear. 2) When closing the (last) window the menu bar disappears mostly, except for the LyX menu. This was also reported by Stephan Witt, but I did observe no crash. When closing the last window Qt5 should switch to the "default menu bar" but apparently it doesn't find one and creates it's own minimal default menu bar. The default menu bar is created by GlobalMenuBar() (in GuiApplication.cpp) which has a constructor GlobalMenuBar() : new QMenuBar(0); according to the Qt docs the first parent-less QMenuBar created will be used as the default menu bar. Apparently Qt5 does not detect the QMenuBar(0) created via a subclass; When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is solved. GlobalMenuBar() was introduced to override the event() function to handle QEvent::ShortcutOverride events but shortcuts seem to work without using the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only work after first activating one of them via the menu, but the latter also happens in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 confirms that GlobalMenuBar's event() is not called when issuing a shortcut with no window present. I assume that these standard mac-shortcuts are handled automatically by Qt. If someone wants to check this, see the attached patch, which includes all changes (but does not solve issue 1)). Patrick De Visschere >>> >>> Hi Patrick, >>> >>> the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a >>> while with the Qt5 build and failed to solve this issue 2. This I did >>> while being on vacation, so I couldn't answer earlier. >>> >>> The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused >>> by Qt5 not showing a menu top item without any action attached. The >>> latest change is the dummy action has to be attached to the sub menu >>> after the addMenu(subMenu) method call. >> >> I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does >> include this dummy action, if I’m not mistaken. > > Yes, me too. But this dummy action is added before the addMenu(menu) > method call. I've had to move it the addAction call after the addMenu > call. > >>> Both issues are regressions of Qt5, IMO. >>> >>> The QMacStyle doesn't need to be replaced if LyX is linked with the >>> QMacExtras framework. >>> >>> Regarding the Q_WS_MACX macro replacement I'm not sure what should be >>> done. >>> >>> 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is >>> available since 4.6.x at least. >>> 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and >>> Q_OS_WIN at the same time but cannot test all platforms. >>> >>> This results in the attached patch. It contains some additional changes >>> in Menu.cpp I introduced while attacking the issue 2. Furthermore I >>> changed CMakeLists.txt because of some warnings from newer cmake. >>> >>> This patch should not be commit as is but in some separate steps. >>> Please, if someone can try it or comment on it, I'd like to hear other >>> opinions. >>> >> >> With this patch I get basically the same behaviour as I described in my >> initial message. Without a window being present, Cmd-O and Cmd-N don’t >> work right away. And the application still starts without the menubar >> being visible (issue 1), but the shortcuts do work. > > Ok, that's not good. > > But on my system the menu bar is visible on startup. > > So, I'll give more details regarding my build environment: > * Mac OS X 10.8.5 > * Darwin Kernel Version 12.5.0
Re: LyX+Qt5 build (CMake+XCode) on OS X
Am 20.08.2014 um 22:45 schrieb Patrick De Visschere : > On 20 Aug, 2014, at 11:22 , Stephan Witt wrote: > >> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere : >> >>> On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: >>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere : >>> >>> My environment >>> >>> * Mac OS X 10.9.4 >>> * Darwin Kernel Version 13.3.0 >>> * Qt 5.3.1 (stable branch) (default Cocoa) >>> ./configure -opensource -silent -shared -release -no-dbus -nomake examples >>> -nomake tools -no-framework >> >> You don't build the libraries as frameworks. I'm not sure if this makes no >> difference. >> >> I'm using the Qt frameworks I've build myself. >> >> Stephan > > Stephan, > > I was planning to do that. (the qt-debug build does not make a difference as > you expected) > > I suppose you use the LyX-Mac-binary-release.sh script. > > I have never managed to use this script without making changes to it, perhaps > because I’m using it the wrong way. > > I build qt as a framework separately and would then use the script like: > > sh development/LyX-Mac-binary-release.sh --with-qt-frameworks=yes > --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 > --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 > --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug > > I think the --with-qt-frameworks=yes is needed to include qt as a framework; > > and --with-qt-dir=/… points to the dir where the qt-framework has been > installed (previously). > > I’m not sure about the exact meaning of --qt-deployment=yes but I think I > need it too. > > What I don’t understand are the lines 260-262 > if [ "${configure_qt_frameworks}" != "yes" ]; then > QtInstallDir=${QTDIR:-"/opt/qt4"} > fi > > with --with-qt-frameworks=yes, QtInstallDir is not set. > > Therefore I uncomment the if/fi so that > QtInstallDir=${QTDIR:-"/opt/qt4”} > > is always executed and QtInstallDir points to my qt-install dir. > > In addition I must modify some CPPFLAGS= ... > > Any idea what I’m doing wrong? > > Patrick De Visschere Perhaps I should remove the --with-qt-frameworks switch. I don't use it anymore and it was meant as "with the frameworks by Qt (Nokia)". The --qt-deployment=yes is default and with it the script copies the frameworks to the package. This is needed if you want to use the LyX app on another system. I'd avoid the --with-libiconv-prefix=/opt/local switch. This is the shell script I'm using for calling LyX-Mac-binary-release.sh: #!/bin/sh ARCH=x86_64 QtVersion=5.3.1 QtAPI=-cocoa LyXVersion=lyx CC=cc CXX=c++ \ QtConfigureOptions="-debug-and-release" QtAPI=${QtAPI} QtVersion=${QtVersion} \ sh ${MKFLAGS} ${LyXVersion}/development/LyX-Mac-binary-release.sh \ --with-sdkroot=10.8 --with-macosx-target=10.6 --with-arch=${ARCH} \ --with-qt-dir=/Users/Shared/LyX/qt-${QtVersion}-frameworks${QtAPI}-${ARCH} \ "$@" Stephan
Re: LyX+Qt5 build (CMake+XCode) on OS X
On 20 Aug, 2014, at 11:22 , Stephan Witt wrote: > Am 19.08.2014 um 22:41 schrieb Patrick De Visschere : > >> On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: >> >>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere : >> >> My environment >> >> * Mac OS X 10.9.4 >> * Darwin Kernel Version 13.3.0 >> * Qt 5.3.1 (stable branch) (default Cocoa) >> ./configure -opensource -silent -shared -release -no-dbus -nomake examples >> -nomake tools -no-framework > > You don't build the libraries as frameworks. I'm not sure if this makes no > difference. > > I'm using the Qt frameworks I've build myself. > > Stephan Stephan, I was planning to do that. (the qt-debug build does not make a difference as you expected) I suppose you use the LyX-Mac-binary-release.sh script. I have never managed to use this script without making changes to it, perhaps because I’m using it the wrong way. I build qt as a framework separately and would then use the script like: sh development/LyX-Mac-binary-release.sh --with-qt-frameworks=yes --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug I think the --with-qt-frameworks=yes is needed to include qt as a framework; and --with-qt-dir=/… points to the dir where the qt-framework has been installed (previously). I’m not sure about the exact meaning of --qt-deployment=yes but I think I need it too. What I don’t understand are the lines 260-262 if [ "${configure_qt_frameworks}" != "yes" ]; then QtInstallDir=${QTDIR:-"/opt/qt4"} fi with --with-qt-frameworks=yes, QtInstallDir is not set. Therefore I uncomment the if/fi so that QtInstallDir=${QTDIR:-"/opt/qt4”} is always executed and QtInstallDir points to my qt-install dir. In addition I must modify some CPPFLAGS= ... Any idea what I’m doing wrong? Patrick De Visschere
Re: LyX+Qt5 build (CMake+XCode) on OS X
Am 20.08.2014 um 20:46 schrieb Patrick De Visschere : > On 20 Aug, 2014, at 08:40 , Stephan Witt wrote: > >> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere : >> >>> On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: >>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere : > On 15 Aug, 2014, at 13:57 , Stephan Witt wrote: > >> Am 12.08.2014 um 22:07 schrieb pdv : >> >>> As a follow-up on reports in the thread "LyX on OS X 10.9" from some >>> months ago, I build LyX(master) + Qt5(stable) (CMake + XCode). >>> >>> I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by >>> QProxyStyle and observed then (at least) 2 issues: >>> >>> 1) When starting up the menu bar is not visible; One must switch to >>> another app and then bring lyx to the foreground to make the menu bar >>> appear. >>> 2) When closing the (last) window the menu bar disappears mostly, >>> except for the LyX menu. This was also reported by Stephan Witt, but I >>> did observe no crash. >>> >>> When closing the last window Qt5 should switch to the "default menu >>> bar" but apparently it doesn't find one and creates it's own minimal >>> default menu bar. >>> The default menu bar is created by GlobalMenuBar() (in >>> GuiApplication.cpp) which has a constructor GlobalMenuBar() : new >>> QMenuBar(0); according to the Qt docs the first parent-less QMenuBar >>> created will be used as the default menu bar. Apparently Qt5 does not >>> detect the QMenuBar(0) created via a subclass; >>> >>> When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is >>> solved. >>> >>> GlobalMenuBar() was introduced to override the event() function to >>> handle QEvent::ShortcutOverride events but shortcuts seem to work >>> without using the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; >>> Cmd-N and Cmd-O only work after first activating one of them via the >>> menu, but the latter also happens in LyX211 and may not be related to >>> Qt5). Building LyX + Qt4.8.6 confirms that GlobalMenuBar's event() is >>> not called when issuing a shortcut with no window present. I assume >>> that these standard mac-shortcuts are handled automatically by Qt. >>> >>> If someone wants to check this, see the attached patch, which includes >>> all changes (but does not solve issue 1)). >>> >>> Patrick De Visschere >>> >> >> Hi Patrick, >> >> the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a >> while with the Qt5 build and failed to solve this issue 2. This I did >> while being on vacation, so I couldn't answer earlier. >> >> The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by >> Qt5 not showing a menu top item without any action attached. The latest >> change is the dummy action has to be attached to the sub menu after the >> addMenu(subMenu) method call. > > I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does > include this dummy action, if I’m not mistaken. Yes, me too. But this dummy action is added before the addMenu(menu) method call. I've had to move it the addAction call after the addMenu call. >> Both issues are regressions of Qt5, IMO. >> >> The QMacStyle doesn't need to be replaced if LyX is linked with the >> QMacExtras framework. >> >> Regarding the Q_WS_MACX macro replacement I'm not sure what should be >> done. >> >> 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is >> available since 4.6.x at least. >> 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and >> Q_OS_WIN at the same time but cannot test all platforms. >> >> This results in the attached patch. It contains some additional changes >> in Menu.cpp I introduced while attacking the issue 2. Furthermore I >> changed CMakeLists.txt because of some warnings from newer cmake. >> >> This patch should not be commit as is but in some separate steps. >> Please, if someone can try it or comment on it, I'd like to hear other >> opinions. >> > > With this patch I get basically the same behaviour as I described in my > initial message. Without a window being present, Cmd-O and Cmd-N don’t > work right away. And the application still starts without the menubar > being visible (issue 1), but the shortcuts do work. Ok, that's not good. But on my system the menu bar is visible on startup. So, I'll give more details regarding my build environment: * Mac OS X 10.8.5 * Darwin Kernel Version 12.5.0 * Qt 5.3.1 Cocoa built with: $ configure -debug-and-release -opensource -silent -shared -confirm-license -no-strip -no-kms -no-pkg-config -nomake exa
Re: LyX+Qt5 build (CMake+XCode) on OS X
On 20 Aug, 2014, at 08:40 , Stephan Witt wrote: > Am 19.08.2014 um 22:41 schrieb Patrick De Visschere : > >> >> On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: >> >>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere : >>> On 15 Aug, 2014, at 13:57 , Stephan Witt wrote: > Am 12.08.2014 um 22:07 schrieb pdv : > >> As a follow-up on reports in the thread "LyX on OS X 10.9" from some >> months ago, I build LyX(master) + Qt5(stable) (CMake + XCode). >> >> I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle >> and observed then (at least) 2 issues: >> >> 1) When starting up the menu bar is not visible; One must switch to >> another app and then bring lyx to the foreground to make the menu bar >> appear. >> 2) When closing the (last) window the menu bar disappears mostly, except >> for the LyX menu. This was also reported by Stephan Witt, but I did >> observe no crash. >> >> When closing the last window Qt5 should switch to the "default menu bar" >> but apparently it doesn't find one and creates it's own minimal default >> menu bar. >> The default menu bar is created by GlobalMenuBar() (in >> GuiApplication.cpp) which has a constructor GlobalMenuBar() : new >> QMenuBar(0); according to the Qt docs the first parent-less QMenuBar >> created will be used as the default menu bar. Apparently Qt5 does not >> detect the QMenuBar(0) created via a subclass; >> >> When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is >> solved. >> >> GlobalMenuBar() was introduced to override the event() function to >> handle QEvent::ShortcutOverride events but shortcuts seem to work >> without using the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N >> and Cmd-O only work after first activating one of them via the menu, but >> the latter also happens in LyX211 and may not be related to Qt5). >> Building LyX + Qt4.8.6 confirms that GlobalMenuBar's event() is not >> called when issuing a shortcut with no window present. I assume that >> these standard mac-shortcuts are handled automatically by Qt. >> >> If someone wants to check this, see the attached patch, which includes >> all changes (but does not solve issue 1)). >> >> Patrick De Visschere >> > > Hi Patrick, > > the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a > while with the Qt5 build and failed to solve this issue 2. This I did > while being on vacation, so I couldn't answer earlier. > > The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by > Qt5 not showing a menu top item without any action attached. The latest > change is the dummy action has to be attached to the sub menu after the > addMenu(subMenu) method call. I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does include this dummy action, if I’m not mistaken. >>> >>> Yes, me too. But this dummy action is added before the addMenu(menu) method >>> call. I've had to move it the addAction call after the addMenu call. >>> > Both issues are regressions of Qt5, IMO. > > The QMacStyle doesn't need to be replaced if LyX is linked with the > QMacExtras framework. > > Regarding the Q_WS_MACX macro replacement I'm not sure what should be > done. > > 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is > available since 4.6.x at least. > 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and Q_OS_WIN > at the same time but cannot test all platforms. > > This results in the attached patch. It contains some additional changes > in Menu.cpp I introduced while attacking the issue 2. Furthermore I > changed CMakeLists.txt because of some warnings from newer cmake. > > This patch should not be commit as is but in some separate steps. Please, > if someone can try it or comment on it, I'd like to hear other opinions. > With this patch I get basically the same behaviour as I described in my initial message. Without a window being present, Cmd-O and Cmd-N don’t work right away. And the application still starts without the menubar being visible (issue 1), but the shortcuts do work. >>> >>> Ok, that's not good. >>> >>> But on my system the menu bar is visible on startup. >>> >>> So, I'll give more details regarding my build environment: >>> * Mac OS X 10.8.5 >>> * Darwin Kernel Version 12.5.0 >>> * Qt 5.3.1 Cocoa built with: >>> $ configure -debug-and-release -opensource -silent -shared -confirm-license >>> -no-strip -no-kms -no-pkg-config -nomake examples -nomake tools -skip >>> qtquick1 -skip qtwebkit -skip qtconnectivity -skip qtquickcontrols -skip >>> qtdeclarative -skip qtscript -arch x86_64 -prefix >>> /Users/
Re: LyX+Qt5 build (CMake+XCode) on OS X
Am 19.08.2014 um 22:41 schrieb Patrick De Visschere : > On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: > >> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere : > > My environment > > * Mac OS X 10.9.4 > * Darwin Kernel Version 13.3.0 > * Qt 5.3.1 (stable branch) (default Cocoa) > ./configure -opensource -silent -shared -release -no-dbus -nomake examples > -nomake tools -no-framework You don't build the libraries as frameworks. I'm not sure if this makes no difference. I'm using the Qt frameworks I've build myself. Stephan
Re: LyX+Qt5 build (CMake+XCode) on OS X
Am 20.08.2014 um 08:40 schrieb Stephan Witt : > ... > You said you had tried it with 10.8 deployment target - do you have similar > library dependencies for your resulting LyX? > > Here are mine: Sorry, I forgot to mention how I did it: $ otool -L lyx-build/cmake/2.2.0dev/bin/Debug/LyX > > lyx-build/cmake/2.2.0dev/bin/Debug/LyX: > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) > /Users/Share/LyX/qt-5.3.1-frameworks-cocoa-x86_64/lib/QtCore.framework/Versions/5/QtCore > (compatibility version 5.3.0, current version 5.3.1) > /Users/Share/LyX/qt-5.3.1-frameworks-cocoa-x86_64/lib/QtGui.framework/Versions/5/QtGui > (compatibility version 5.3.0, current version 5.3.1) > /Users/Share/LyX/utilities/lib/libhunspell-1.3.0.dylib (compatibility version > 1.0.0, current version 1.0.0) > /Users/Share/LyX/utilities/lib/libaspell.15.dylib (compatibility version > 17.0.0, current version 17.5.0) > /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility > version 45.0.0, current version 1187.39.0) > /Users/Share/LyX/qt-5.3.1-frameworks-cocoa-x86_64/lib/QtWidgets.framework/Versions/5/QtWidgets > (compatibility version 5.3.0, current version 5.3.1) > /Users/Share/LyX/qt-5.3.1-frameworks-cocoa-x86_64/lib/QtConcurrent.framework/Versions/5/QtConcurrent > (compatibility version 5.3.0, current version 5.3.1) > /Users/Share/LyX/qt-5.3.1-frameworks-cocoa-x86_64/lib/QtMacExtras.framework/Versions/5/QtMacExtras > (compatibility version 5.3.0, current version 5.3.1) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) > /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version > 228.0.0) > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > (compatibility version 150.0.0, current version 744.19.0) > /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version > 56.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 169.3.0) > /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation > (compatibility version 300.0.0, current version 945.18.0) > /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices > (compatibility version 1.0.0, current version 57.0.0) Stephan
Re: LyX+Qt5 build (CMake+XCode) on OS X
Am 19.08.2014 um 22:41 schrieb Patrick De Visschere : > > On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: > >> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere : >> >>> On 15 Aug, 2014, at 13:57 , Stephan Witt wrote: >>> Am 12.08.2014 um 22:07 schrieb pdv : > As a follow-up on reports in the thread "LyX on OS X 10.9" from some > months ago, I build LyX(master) + Qt5(stable) (CMake + XCode). > > I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle > and observed then (at least) 2 issues: > > 1) When starting up the menu bar is not visible; One must switch to > another app and then bring lyx to the foreground to make the menu bar > appear. > 2) When closing the (last) window the menu bar disappears mostly, except > for the LyX menu. This was also reported by Stephan Witt, but I did > observe no crash. > > When closing the last window Qt5 should switch to the "default menu bar" > but apparently it doesn't find one and creates it's own minimal default > menu bar. > The default menu bar is created by GlobalMenuBar() (in > GuiApplication.cpp) which has a constructor GlobalMenuBar() : new > QMenuBar(0); according to the Qt docs the first parent-less QMenuBar > created will be used as the default menu bar. Apparently Qt5 does not > detect the QMenuBar(0) created via a subclass; > > When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is > solved. > > GlobalMenuBar() was introduced to override the event() function to handle > QEvent::ShortcutOverride events but shortcuts seem to work without using > the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only > work after first activating one of them via the menu, but the latter also > happens in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 > confirms that GlobalMenuBar's event() is not called when issuing a > shortcut with no window present. I assume that these standard > mac-shortcuts are handled automatically by Qt. > > If someone wants to check this, see the attached patch, which includes > all changes (but does not solve issue 1)). > > Patrick De Visschere > Hi Patrick, the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a while with the Qt5 build and failed to solve this issue 2. This I did while being on vacation, so I couldn't answer earlier. The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by Qt5 not showing a menu top item without any action attached. The latest change is the dummy action has to be attached to the sub menu after the addMenu(subMenu) method call. >>> >>> I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does >>> include this dummy action, if I’m not mistaken. >> >> Yes, me too. But this dummy action is added before the addMenu(menu) method >> call. I've had to move it the addAction call after the addMenu call. >> Both issues are regressions of Qt5, IMO. The QMacStyle doesn't need to be replaced if LyX is linked with the QMacExtras framework. Regarding the Q_WS_MACX macro replacement I'm not sure what should be done. 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is available since 4.6.x at least. 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and Q_OS_WIN at the same time but cannot test all platforms. This results in the attached patch. It contains some additional changes in Menu.cpp I introduced while attacking the issue 2. Furthermore I changed CMakeLists.txt because of some warnings from newer cmake. This patch should not be commit as is but in some separate steps. Please, if someone can try it or comment on it, I'd like to hear other opinions. >>> >>> With this patch I get basically the same behaviour as I described in my >>> initial message. Without a window being present, Cmd-O and Cmd-N don’t work >>> right away. And the application still starts without the menubar being >>> visible (issue 1), but the shortcuts do work. >> >> Ok, that's not good. >> >> But on my system the menu bar is visible on startup. >> >> So, I'll give more details regarding my build environment: >> * Mac OS X 10.8.5 >> * Darwin Kernel Version 12.5.0 >> * Qt 5.3.1 Cocoa built with: >> $ configure -debug-and-release -opensource -silent -shared -confirm-license >> -no-strip -no-kms -no-pkg-config -nomake examples -nomake tools -skip >> qtquick1 -skip qtwebkit -skip qtconnectivity -skip qtquickcontrols -skip >> qtdeclarative -skip qtscript -arch x86_64 -prefix >> /Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64 >> >> With autotools I build with >> * gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) >
Re: LyX+Qt5 build (CMake+XCode) on OS X
On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: > Am 17.08.2014 um 20:13 schrieb Patrick De Visschere : > >> On 15 Aug, 2014, at 13:57 , Stephan Witt wrote: >> >>> Am 12.08.2014 um 22:07 schrieb pdv : >>> As a follow-up on reports in the thread "LyX on OS X 10.9" from some months ago, I build LyX(master) + Qt5(stable) (CMake + XCode). I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle and observed then (at least) 2 issues: 1) When starting up the menu bar is not visible; One must switch to another app and then bring lyx to the foreground to make the menu bar appear. 2) When closing the (last) window the menu bar disappears mostly, except for the LyX menu. This was also reported by Stephan Witt, but I did observe no crash. When closing the last window Qt5 should switch to the "default menu bar" but apparently it doesn't find one and creates it's own minimal default menu bar. The default menu bar is created by GlobalMenuBar() (in GuiApplication.cpp) which has a constructor GlobalMenuBar() : new QMenuBar(0); according to the Qt docs the first parent-less QMenuBar created will be used as the default menu bar. Apparently Qt5 does not detect the QMenuBar(0) created via a subclass; When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is solved. GlobalMenuBar() was introduced to override the event() function to handle QEvent::ShortcutOverride events but shortcuts seem to work without using the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only work after first activating one of them via the menu, but the latter also happens in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 confirms that GlobalMenuBar's event() is not called when issuing a shortcut with no window present. I assume that these standard mac-shortcuts are handled automatically by Qt. If someone wants to check this, see the attached patch, which includes all changes (but does not solve issue 1)). Patrick De Visschere >>> >>> Hi Patrick, >>> >>> the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a while >>> with the Qt5 build and failed to solve this issue 2. This I did while being >>> on vacation, so I couldn't answer earlier. >>> >>> The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by >>> Qt5 not showing a menu top item without any action attached. The latest >>> change is the dummy action has to be attached to the sub menu after the >>> addMenu(subMenu) method call. >> >> I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does >> include this dummy action, if I’m not mistaken. > > Yes, me too. But this dummy action is added before the addMenu(menu) method > call. I've had to move it the addAction call after the addMenu call. > >>> Both issues are regressions of Qt5, IMO. >>> >>> The QMacStyle doesn't need to be replaced if LyX is linked with the >>> QMacExtras framework. >>> >>> Regarding the Q_WS_MACX macro replacement I'm not sure what should be done. >>> >>> 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is available >>> since 4.6.x at least. >>> 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and Q_OS_WIN >>> at the same time but cannot test all platforms. >>> >>> This results in the attached patch. It contains some additional changes in >>> Menu.cpp I introduced while attacking the issue 2. Furthermore I changed >>> CMakeLists.txt because of some warnings from newer cmake. >>> >>> This patch should not be commit as is but in some separate steps. Please, >>> if someone can try it or comment on it, I'd like to hear other opinions. >>> >> >> With this patch I get basically the same behaviour as I described in my >> initial message. Without a window being present, Cmd-O and Cmd-N don’t work >> right away. And the application still starts without the menubar being >> visible (issue 1), but the shortcuts do work. > > Ok, that's not good. > > But on my system the menu bar is visible on startup. > > So, I'll give more details regarding my build environment: > * Mac OS X 10.8.5 > * Darwin Kernel Version 12.5.0 > * Qt 5.3.1 Cocoa built with: > $ configure -debug-and-release -opensource -silent -shared -confirm-license > -no-strip -no-kms -no-pkg-config -nomake examples -nomake tools -skip > qtquick1 -skip qtwebkit -skip qtconnectivity -skip qtquickcontrols -skip > qtdeclarative -skip qtscript -arch x86_64 -prefix > /Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64 > > With autotools I build with > * gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) > > With cmake I build with > * AppleClang 5.1.0.5030040 (Apple LLVM 5.1) > > The LyX package I made on a Mac 10.6.8 works like the package build on 10.8.5. My environm
Re: LyX+Qt5 build (CMake+XCode) on OS X
Am 17.08.2014 um 20:13 schrieb Patrick De Visschere : > On 15 Aug, 2014, at 13:57 , Stephan Witt wrote: > >> Am 12.08.2014 um 22:07 schrieb pdv : >> >>> As a follow-up on reports in the thread "LyX on OS X 10.9" from some months >>> ago, I build LyX(master) + Qt5(stable) (CMake + XCode). >>> >>> I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle >>> and observed then (at least) 2 issues: >>> >>> 1) When starting up the menu bar is not visible; One must switch to another >>> app and then bring lyx to the foreground to make the menu bar appear. >>> 2) When closing the (last) window the menu bar disappears mostly, except >>> for the LyX menu. This was also reported by Stephan Witt, but I did observe >>> no crash. >>> >>> When closing the last window Qt5 should switch to the "default menu bar" >>> but apparently it doesn't find one and creates it's own minimal default >>> menu bar. >>> The default menu bar is created by GlobalMenuBar() (in GuiApplication.cpp) >>> which has a constructor GlobalMenuBar() : new QMenuBar(0); according to the >>> Qt docs the first parent-less QMenuBar created will be used as the default >>> menu bar. Apparently Qt5 does not detect the QMenuBar(0) created via a >>> subclass; >>> >>> When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is >>> solved. >>> >>> GlobalMenuBar() was introduced to override the event() function to handle >>> QEvent::ShortcutOverride events but shortcuts seem to work without using >>> the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only >>> work after first activating one of them via the menu, but the latter also >>> happens in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 >>> confirms that GlobalMenuBar's event() is not called when issuing a shortcut >>> with no window present. I assume that these standard mac-shortcuts are >>> handled automatically by Qt. >>> >>> If someone wants to check this, see the attached patch, which includes all >>> changes (but does not solve issue 1)). >>> >>> Patrick De Visschere >>> >> >> Hi Patrick, >> >> the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a while >> with the Qt5 build and failed to solve this issue 2. This I did while being >> on vacation, so I couldn't answer earlier. >> >> The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by Qt5 >> not showing a menu top item without any action attached. The latest change >> is the dummy action has to be attached to the sub menu after the >> addMenu(subMenu) method call. > > I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does include > this dummy action, if I’m not mistaken. Yes, me too. But this dummy action is added before the addMenu(menu) method call. I've had to move it the addAction call after the addMenu call. >> Both issues are regressions of Qt5, IMO. >> >> The QMacStyle doesn't need to be replaced if LyX is linked with the >> QMacExtras framework. >> >> Regarding the Q_WS_MACX macro replacement I'm not sure what should be done. >> >> 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is available >> since 4.6.x at least. >> 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and Q_OS_WIN at >> the same time but cannot test all platforms. >> >> This results in the attached patch. It contains some additional changes in >> Menu.cpp I introduced while attacking the issue 2. Furthermore I changed >> CMakeLists.txt because of some warnings from newer cmake. >> >> This patch should not be commit as is but in some separate steps. Please, if >> someone can try it or comment on it, I'd like to hear other opinions. >> > > With this patch I get basically the same behaviour as I described in my > initial message. Without a window being present, Cmd-O and Cmd-N don’t work > right away. And the application still starts without the menubar being > visible (issue 1), but the shortcuts do work. Ok, that's not good. But on my system the menu bar is visible on startup. So, I'll give more details regarding my build environment: * Mac OS X 10.8.5 * Darwin Kernel Version 12.5.0 * Qt 5.3.1 Cocoa built with: $ configure -debug-and-release -opensource -silent -shared -confirm-license -no-strip -no-kms -no-pkg-config -nomake examples -nomake tools -skip qtquick1 -skip qtwebkit -skip qtconnectivity -skip qtquickcontrols -skip qtdeclarative -skip qtscript -arch x86_64 -prefix /Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64 With autotools I build with * gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) With cmake I build with * AppleClang 5.1.0.5030040 (Apple LLVM 5.1) The LyX package I made on a Mac 10.6.8 works like the package build on 10.8.5.
Re: LyX+Qt5 build (CMake+XCode) on OS X
On 15 Aug, 2014, at 13:57 , Stephan Witt wrote: > Am 12.08.2014 um 22:07 schrieb pdv : > >> As a follow-up on reports in the thread "LyX on OS X 10.9" from some months >> ago, I build LyX(master) + Qt5(stable) (CMake + XCode). >> >> I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle and >> observed then (at least) 2 issues: >> >> 1) When starting up the menu bar is not visible; One must switch to another >> app and then bring lyx to the foreground to make the menu bar appear. >> 2) When closing the (last) window the menu bar disappears mostly, except for >> the LyX menu. This was also reported by Stephan Witt, but I did observe no >> crash. >> >> When closing the last window Qt5 should switch to the "default menu bar" but >> apparently it doesn't find one and creates it's own minimal default menu bar. >> The default menu bar is created by GlobalMenuBar() (in GuiApplication.cpp) >> which has a constructor GlobalMenuBar() : new QMenuBar(0); according to the >> Qt docs the first parent-less QMenuBar created will be used as the default >> menu bar. Apparently Qt5 does not detect the QMenuBar(0) created via a >> subclass; >> >> When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is >> solved. >> >> GlobalMenuBar() was introduced to override the event() function to handle >> QEvent::ShortcutOverride events but shortcuts seem to work without using the >> GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only work >> after first activating one of them via the menu, but the latter also happens >> in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 confirms >> that GlobalMenuBar's event() is not called when issuing a shortcut with no >> window present. I assume that these standard mac-shortcuts are handled >> automatically by Qt. >> >> If someone wants to check this, see the attached patch, which includes all >> changes (but does not solve issue 1)). >> >> Patrick De Visschere >> > > Hi Patrick, > > the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a while > with the Qt5 build and failed to solve this issue 2. This I did while being > on vacation, so I couldn't answer earlier. > > The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by Qt5 > not showing a menu top item without any action attached. The latest change is > the dummy action has to be attached to the sub menu after the > addMenu(subMenu) method call. I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does include this dummy action, if I’m not mistaken. > > Both issues are regressions of Qt5, IMO. > > The QMacStyle doesn't need to be replaced if LyX is linked with the > QMacExtras framework. > > Regarding the Q_WS_MACX macro replacement I'm not sure what should be done. > > 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is available > since 4.6.x at least. > 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and Q_OS_WIN at > the same time but cannot test all platforms. > > This results in the attached patch. It contains some additional changes in > Menu.cpp I introduced while attacking the issue 2. Furthermore I changed > CMakeLists.txt because of some warnings from newer cmake. > > This patch should not be commit as is but in some separate steps. Please, if > someone can try it or comment on it, I'd like to hear other opinions. > With this patch I get basically the same behaviour as I described in my initial message. Without a window being present, Cmd-O and Cmd-N don’t work right away. And the application still starts without the menubar being visible (issue 1), but the shortcuts do work. Patrick De Visschere > Stephan > > <2014-08-15-Qt5.patch>
Re: LyX+Qt5 build (CMake+XCode) on OS X
Am 12.08.2014 um 22:07 schrieb pdv : > As a follow-up on reports in the thread "LyX on OS X 10.9" from some months > ago, I build LyX(master) + Qt5(stable) (CMake + XCode). > > I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle and > observed then (at least) 2 issues: > > 1) When starting up the menu bar is not visible; One must switch to another > app and then bring lyx to the foreground to make the menu bar appear. > 2) When closing the (last) window the menu bar disappears mostly, except for > the LyX menu. This was also reported by Stephan Witt, but I did observe no > crash. > > When closing the last window Qt5 should switch to the "default menu bar" but > apparently it doesn't find one and creates it's own minimal default menu bar. > The default menu bar is created by GlobalMenuBar() (in GuiApplication.cpp) > which has a constructor GlobalMenuBar() : new QMenuBar(0); according to the > Qt docs the first parent-less QMenuBar created will be used as the default > menu bar. Apparently Qt5 does not detect the QMenuBar(0) created via a > subclass; > > When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is solved. > > GlobalMenuBar() was introduced to override the event() function to handle > QEvent::ShortcutOverride events but shortcuts seem to work without using the > GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only work > after first activating one of them via the menu, but the latter also happens > in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 confirms > that GlobalMenuBar's event() is not called when issuing a shortcut with no > window present. I assume that these standard mac-shortcuts are handled > automatically by Qt. > > If someone wants to check this, see the attached patch, which includes all > changes (but does not solve issue 1)). > > Patrick De Visschere > Hi Patrick, the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a while with the Qt5 build and failed to solve this issue 2. This I did while being on vacation, so I couldn't answer earlier. The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by Qt5 not showing a menu top item without any action attached. The latest change is the dummy action has to be attached to the sub menu after the addMenu(subMenu) method call. Both issues are regressions of Qt5, IMO. The QMacStyle doesn't need to be replaced if LyX is linked with the QMacExtras framework. Regarding the Q_WS_MACX macro replacement I'm not sure what should be done. 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is available since 4.6.x at least. 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and Q_OS_WIN at the same time but cannot test all platforms. This results in the attached patch. It contains some additional changes in Menu.cpp I introduced while attacking the issue 2. Furthermore I changed CMakeLists.txt because of some warnings from newer cmake. This patch should not be commit as is but in some separate steps. Please, if someone can try it or comment on it, I'd like to hear other opinions. Stephan 2014-08-15-Qt5.patch Description: Binary data
Re: LyX+Qt5 build (CMake+XCode) on OS X
On 13/8/14, 04:06 , Scott Kostyshak wrote: On Tue, Aug 12, 2014 at 4:07 PM, pdv wrote: As a follow-up on reports in the thread "LyX on OS X 10.9" from some months ago, I build LyX(master) + Qt5(stable) (CMake + XCode). I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle and observed then (at least) 2 issues: 1) When starting up the menu bar is not visible; One must switch to another app and then bring lyx to the foreground to make the menu bar appear. 2) When closing the (last) window the menu bar disappears mostly, except for the LyX menu. This was also reported by Stephan Witt, but I did observe no crash. When closing the last window Qt5 should switch to the "default menu bar" but apparently it doesn't find one and creates it's own minimal default menu bar. The default menu bar is created by GlobalMenuBar() (in GuiApplication.cpp) which has a constructor GlobalMenuBar() : new QMenuBar(0); according to the Qt docs the first parent-less QMenuBar created will be used as the default menu bar. Apparently Qt5 does not detect the QMenuBar(0) created via a subclass; When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is solved. GlobalMenuBar() was introduced to override the event() function to handle QEvent::ShortcutOverride events but shortcuts seem to work without using the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only work after first activating one of them via the menu, but the latter also happens in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 confirms that GlobalMenuBar's event() is not called when issuing a shortcut with no window present. I assume that these standard mac-shortcuts are handled automatically by Qt. If someone wants to check this, see the attached patch, which includes all changes (but does not solve issue 1)). I wonder if this is related to the Ubuntu issue that I and Abdel noticed: https://bugs.launchpad.net/ubuntu/+source/appmenu-qt5/+bug/1307619 For 1, does running LyX as lyx -x "ui-toggle menubar" fix it (or running that command twice directly in LyX from the command buffer)? Of course this is just a work around but I wonder if it helps narrow down the problem. Scott It does not help (neither of them). Patrick De Visschere
Re: LyX+Qt5 build (CMake+XCode) on OS X
On Tue, Aug 12, 2014 at 4:07 PM, pdv wrote: > As a follow-up on reports in the thread "LyX on OS X 10.9" from some months > ago, I build LyX(master) + Qt5(stable) (CMake + XCode). > > I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle and > observed then (at least) 2 issues: > > 1) When starting up the menu bar is not visible; One must switch to another > app and then bring lyx to the foreground to make the menu bar appear. > 2) When closing the (last) window the menu bar disappears mostly, except for > the LyX menu. This was also reported by Stephan Witt, but I did observe no > crash. > > When closing the last window Qt5 should switch to the "default menu bar" but > apparently it doesn't find one and creates it's own minimal default menu > bar. > The default menu bar is created by GlobalMenuBar() (in GuiApplication.cpp) > which has a constructor GlobalMenuBar() : new QMenuBar(0); according to the > Qt docs the first parent-less QMenuBar created will be used as the default > menu bar. Apparently Qt5 does not detect the QMenuBar(0) created via a > subclass; > > When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is > solved. > > GlobalMenuBar() was introduced to override the event() function to handle > QEvent::ShortcutOverride events but shortcuts seem to work without using the > GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only work > after first activating one of them via the menu, but the latter also happens > in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 confirms > that GlobalMenuBar's event() is not called when issuing a shortcut with no > window present. I assume that these standard mac-shortcuts are handled > automatically by Qt. > > If someone wants to check this, see the attached patch, which includes all > changes (but does not solve issue 1)). I wonder if this is related to the Ubuntu issue that I and Abdel noticed: https://bugs.launchpad.net/ubuntu/+source/appmenu-qt5/+bug/1307619 For 1, does running LyX as lyx -x "ui-toggle menubar" fix it (or running that command twice directly in LyX from the command buffer)? Of course this is just a work around but I wonder if it helps narrow down the problem. Scott