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>


Reply via email to