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.
