Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

Sent from my iPad

 On 25 Aug 2014, at 07:55, Stephan Witt st.w...@gmx.net wrote:
 
 Am 23.08.2014 um 18:01 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 23 Aug, 2014, at 14:50 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 23.08.2014 um 12:01 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 23:15 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 20.08.2014 um 22:45 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 11:22 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 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

[Patrick De Visschere]

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
>>> 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Stephan Witt]

Am 23.08.2014 um 18:01 schrieb Patrick De Visschere pdvissch...@edpnet.be:

 On 23 Aug, 2014, at 14:50 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 23.08.2014 um 12:01 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 23:15 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 20.08.2014 um 22:45 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 11:22 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 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 \
 ${LYX_USE_QT} \
 ${SPELLER_OPTIONS} \
 $@
 )
 # end of script
 
 I'm 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Stephan Witt]

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 \
>>  

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 20 Aug, 2014, at 23:15 , Stephan Witt st.w...@gmx.net wrote:

 Am 20.08.2014 um 22:45 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 11:22 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 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
CPPFLAGS=${CPPFLAGS} -F${QtInstallDir}/lib
LDFLAGS=-L/usr/lib ${LDFLAGS} -F${QtInstallDir}/lib 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Stephan Witt]

Am 23.08.2014 um 12:01 schrieb Patrick De Visschere pdvissch...@edpnet.be:

 On 20 Aug, 2014, at 23:15 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 20.08.2014 um 22:45 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 11:22 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 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 \
  ${LYX_USE_QT} \
  ${SPELLER_OPTIONS} \
  $@
)
# end of script

I'm using only self made libraries with Xcode too. Therefore I can work with 
both environments, Xcode for debugging and autotools for packaging.

 There 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 23 Aug, 2014, at 14:50 , Stephan Witt st.w...@gmx.net wrote:

 Am 23.08.2014 um 12:01 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 23:15 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 20.08.2014 um 22:45 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 11:22 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 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 \
  ${LYX_USE_QT} \
  ${SPELLER_OPTIONS} \
  $@
 )
 # end of script
 
 I'm using only self made libraries with Xcode too. Therefore I 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[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.

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"
  

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Stephan Witt]

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 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[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_DIR=${LyxUtilDir}/include \
>   

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Stephan Witt]

Am 15.08.2014 um 13:57 schrieb Stephan Witt st.w...@gmx.net:

 Am 12.08.2014 um 22:07 schrieb pdv pdvissch...@edpnet.be:
 
 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
 Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff
 
 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

[Stephan Witt]

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

[Stephan Witt]

Am 20.08.2014 um 23:31 schrieb Patrick De Visschere pdvissch...@edpnet.be:

 On 20 Aug, 2014, at 22:40 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 20.08.2014 um 20:46 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 08:40 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 15 Aug, 2014, at 13:57 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 12.08.2014 um 22:07 schrieb pdv pdvissch...@edpnet.be:
 
 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
 Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff
 
 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 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Stephan Witt]

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, 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Stephan Witt]

Am 19.08.2014 um 22:41 schrieb Patrick De Visschere pdvissch...@edpnet.be:

 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 15 Aug, 2014, at 13:57 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 12.08.2014 um 22:07 schrieb pdv pdvissch...@edpnet.be:
 
 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
 Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff
 
 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 environment
 
 * Mac OS X 10.9.4
 * Darwin Kernel Version 13.3.0
 * Qt 5.3.1 (stable branch) (default Cocoa)
 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Stephan Witt]

Am 20.08.2014 um 08:40 schrieb Stephan Witt st.w...@gmx.net:

 ...
 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

[Stephan Witt]

Am 19.08.2014 um 22:41 schrieb Patrick De Visschere pdvissch...@edpnet.be:

 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 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

[Patrick De Visschere]

On 20 Aug, 2014, at 08:40 , Stephan Witt st.w...@gmx.net wrote:

 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 15 Aug, 2014, at 13:57 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 12.08.2014 um 22:07 schrieb pdv pdvissch...@edpnet.be:
 
 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
 Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff
 
 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 environment
 
 * Mac OS X 10.9.4
 * Darwin Kernel 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Stephan Witt]

Am 20.08.2014 um 20:46 schrieb Patrick De Visschere pdvissch...@edpnet.be:

 On 20 Aug, 2014, at 08:40 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 15 Aug, 2014, at 13:57 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 12.08.2014 um 22:07 schrieb pdv pdvissch...@edpnet.be:
 
 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
 Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff
 
 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 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 20 Aug, 2014, at 11:22 , Stephan Witt st.w...@gmx.net wrote:

 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 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

[Stephan Witt]

Am 20.08.2014 um 22:45 schrieb Patrick De Visschere pdvissch...@edpnet.be:

 On 20 Aug, 2014, at 11:22 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 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

[Patrick De Visschere]

On 20 Aug, 2014, at 22:40 , Stephan Witt st.w...@gmx.net wrote:

 Am 20.08.2014 um 20:46 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 08:40 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 15 Aug, 2014, at 13:57 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 12.08.2014 um 22:07 schrieb pdv pdvissch...@edpnet.be:
 
 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
 Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff
 
 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 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Stephan Witt]

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 
>> 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Stephan Witt]

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

[Stephan Witt]

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

[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 examples 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Stephan Witt]

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 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[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

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Stephan Witt]

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

[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. 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Stephan Witt]

Am 17.08.2014 um 20:13 schrieb Patrick De Visschere pdvissch...@edpnet.be:

 On 15 Aug, 2014, at 13:57 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 12.08.2014 um 22:07 schrieb pdv pdvissch...@edpnet.be:
 
 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
 Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff
 
 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

[Patrick De Visschere]

On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:

 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 15 Aug, 2014, at 13:57 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 12.08.2014 um 22:07 schrieb pdv pdvissch...@edpnet.be:
 
 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
 Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff
 
 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 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 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Stephan Witt]

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

[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)
> 
> With cmake I build with 
> * AppleClang 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 15 Aug, 2014, at 13:57 , Stephan Witt st.w...@gmx.net wrote:

 Am 12.08.2014 um 22:07 schrieb pdv pdvissch...@edpnet.be:
 
 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
 Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff
 
 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

[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.

> 
> 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

[Stephan Witt]

Am 12.08.2014 um 22:07 schrieb pdv pdvissch...@edpnet.be:

 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
 Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff

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

[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.

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

[pdv]

On 13/8/14, 04:06 , Scott Kostyshak wrote:

On Tue, Aug 12, 2014 at 4:07 PM, pdv pdvissch...@edpnet.be 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

[pdv]

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

[Scott Kostyshak]

On Tue, Aug 12, 2014 at 4:07 PM, pdv pdvissch...@edpnet.be 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

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Scott Kostyshak]

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