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 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 -no-framework >>>>> >>>>> * I used cmake 3.0.0 and Xcode 5.1.1, compiler is the same as yours: >>>>> Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) >>>>> Target: x86_64-apple-darwin13.3.0 >>>>> Thread model: posix >>>>> >>>>> I’ve build for 10.8 with "compiler default” C++ settings, or for >>>>> 10.9 with c++11 and libc++ settings, >>>>> with the same result; >>>>> >>>>> Although I haven’t a clue where to start debugging issue 1, I think I'll >>>>> start by building the -debug version of qt5. >>>>> Or could it be a 10.9 issue? >>>> >>>> Building the debug version is an option to attack the issue. On a Mac this >>>> results in two separate shared libraries in the Qt frameworks. E.g. QtCore >>>> and QtCore_debug inside the QtCore.framework - at runtime one may activate >>>> the debug version via environment DYLD_IMAGE_SUFFIX=_debug. AFAIK, the >>>> additional debug version for Qt is build by an separate make call - so I >>>> would be surprised if it improves the situation at runtime. But of course, >>>> you have the option to step into Qt calls after building the debug >>>> libraries. >>>> >>>> I think it's more likely an issue with 10.9 - perhaps a compile time or an >>>> runtime issue or both. >>>> >>>> You said you had tried it with 10.8 deployment target - do you have >>>> similar library dependencies for your resulting LyX? >>>> >>>> Here are mine: >>>> 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 >>> >>> Mine are very similar but libiconv and zlib are different (I use the >>> macports versions) and I have 2 extras: libmagic and /System/…/Cocoa, which >>> I find strange. >>> >>> /usr/local/Qt-5.3.1/lib/libQt5Core.5.dylib (compatibility version >>> 5.3.0, current version 5.3.1) >>> /usr/local/Qt-5.3.1/lib/libQt5Gui.5.dylib (compatibility version 5.3.0, >>> current version 5.3.1) >>> /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current >>> version 8.1.0) >>> /usr/lib/libhunspell-1.2.0.dylib (compatibility version 1.0.0, current >>> version 1.0.0) >>> /opt/local/lib/libaspell.15.dylib (compatibility version 17.0.0, >>> current version 17.5.0) >>> /opt/local/lib/libmagic.1.dylib (compatibility version 2.0.0, current >>> version 2.0.0) >>> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa >>> (compatibility version 1.0.0, current version 19.0.0) >>> /usr/local/Qt-5.3.1/lib/libQt5Widgets.5.dylib (compatibility version >>> 5.3.0, current version 5.3.1) >>> /usr/local/Qt-5.3.1/lib/libQt5Concurrent.5.dylib (compatibility version >>> 5.3.0, current version 5.3.1) >>> /usr/local/Qt-5.3.1/lib/libQt5MacExtras.5.dylib (compatibility version >>> 5.3.0, current version 5.3.1) >>> /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current >>> version 1.2.8) >>> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version >>> 228.0.0) >>> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit >>> (compatibility version 45.0.0, current version 1187.39.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) >> >> Hmm. What's the reason to use the macports versions of zlib and iconv? >> I'd guess you want (or cmake wants) to use aspell from macports and >> this is the price you pay? >> > > If I use the system libraries I get this warning from cmake > > Undefined symbols for architecture x86_64: > "_libiconv", referenced from: > (anonymous namespace)::iconv_codecvt_facet::do_iconv(void*, char > const**, unsigned long*, char**, unsigned long*) const in > libsupport.a(docstream.o) > lyx::IconvProcessor::convert(char const*, unsigned long, char*, unsigned > long) in libsupport.a(unicode.o) > "_libiconv_close", referenced from: > (anonymous namespace)::iconv_codecvt_facet::~iconv_codecvt_facet() in > libsupport.a(docstream.o) > lyx::IconvProcessor::convert(char const*, unsigned long, char*, unsigned > long) in libsupport.a(unicode.o) > lyx::IconvProcessor::Impl::~Impl() in libsupport.a(unicode.o) > "_libiconv_open", referenced from: > (anonymous > namespace)::iconv_codecvt_facet::iconv_codecvt_facet(std::__1::basic_string<char, > std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned > int, unsigned long) in libsupport.a(docstream.o) > lyx::IconvProcessor::init() in libsupport.a(unicode.o) > ld: symbol(s) not found for architecture x86_64 > > and the build fails with linker errors: > > Undefined symbols for architecture x86_64: > "_libiconv", referenced from: > (anonymous namespace)::iconv_codecvt_facet::do_iconv(void*, char > const**, unsigned long*, char**, unsigned long*) const in > libsupport.a(docstream.o) > lyx::IconvProcessor::convert(char const*, unsigned long, char*, unsigned > long) in libsupport.a(unicode.o) > "_libiconv_close", referenced from: > (anonymous namespace)::iconv_codecvt_facet::~iconv_codecvt_facet() in > libsupport.a(docstream.o) > lyx::IconvProcessor::convert(char const*, unsigned long, char*, unsigned > long) in libsupport.a(unicode.o) > lyx::IconvProcessor::Impl::~Impl() in libsupport.a(unicode.o) > "_libiconv_open", referenced from: > (anonymous > namespace)::iconv_codecvt_facet::iconv_codecvt_facet(std::__1::basic_string<char, > std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned > int, unsigned long) in libsupport.a(docstream.o) > lyx::IconvProcessor::init() in libsupport.a(unicode.o) > ld: symbol(s) not found for architecture x86_64 All libraries from macports with iconv references must be linked against macports iconv library. I don't want this because the packaged LyX would have this dependency at runtime too. Therefore I have to provide all libraries for LyX it "wants" to use myself. These are aspell, hunspell and (not yet committed) magic. >> I'm trying hard to avoid the mixture of system libraries with the versions >> from >> macports. In your case I suspect the qt libraries you've built are compiled >> with >> the system versions of these libraries (zlib resp. iconv). You may verify >> this with >> the config.summary file in the qtbase directory of your build tree. (I've >> attached >> the contents of my summary file.) >> >> But I really don't know if and how this can cause the effects you see. >> >> Regarding the Cocoa framework I'm surprised too. libmagic is detected and >> included >> by the cmake Xcode project generator, I think. > > I installed libmagic with macports and cmake finds it. I’ve only installed it > recently to get rid of the cmake warning. It’s probably not needed. Yes it's optional. But aspell has the same effect. >> I uploaded to dropbox the package made by autotools from patched 2.2.0dev. >> Perhaps, >> you can try it and see if it works on your system. >> >> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0dev-2014-08-20%2Bqt5-x86_64-cocoa.dmg >> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0dev-2014-08-20%2Bqt5-x86_64-cocoa.dmg.sig >> > > It works OK. The menubar appears immediately. Fine. It's not a runtime problem at least. Stephan
