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

[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

[Scott Kostyshak]

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

[pdv]

Post by Scott Kostyshak

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

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

[Stephan Witt]

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

[Patrick De Visschere]

Post by Stephan Witt

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

Post by Stephan Witt
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

Post by Stephan Witt
Stephan
<2014-08-15-Qt5.patch>

[Stephan Witt]

Post by Patrick De Visschere

Post by Stephan Witt

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

Post by Patrick De Visschere

Post by Stephan Witt
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.

[Patrick De Visschere]

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

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

Post by Patrick De Visschere

Post by Stephan Witt
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.
* Mac OS X 10.8.5
* Darwin Kernel Version 12.5.0
$ 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?

P. De Visschere

[Stephan Witt]

Post by Patrick De Visschere

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

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

Post by Patrick De Visschere

Post by Stephan Witt
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.
* Mac OS X 10.8.5
* Darwin Kernel Version 12.5.0
$ 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
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

[Stephan Witt]

Post by Stephan Witt
...
You said you had tried it with 10.8 deployment target - do you have similar library dependencies for your resulting LyX?

Sorry, I forgot to mention how I did it:
$ otool -L lyx-build/cmake/2.2.0dev/bin/Debug/LyX

Post by Stephan Witt
/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

[Patrick De Visschere]

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

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

Post by Patrick De Visschere

Post by Stephan Witt
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.
* Mac OS X 10.8.5
* Darwin Kernel Version 12.5.0
$ 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
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?
/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)

[Stephan Witt]

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

Post by Stephan Witt

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

Post by Stephan Witt
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.
* Mac OS X 10.8.5
* Darwin Kernel Version 12.5.0
$ 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
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?
/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?

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

Stephan

[Patrick De Visschere]

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

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

Post by Patrick De Visschere

Post by Stephan Witt
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.
* Mac OS X 10.8.5
* Darwin Kernel Version 12.5.0
$ 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
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?
/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

Post by Stephan Witt
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.

Post by Stephan Witt
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.

Post by Stephan Witt
Stephan
<config.summary>

[Stephan Witt]

Post by Patrick De Visschere

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

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

Post by Patrick De Visschere

Post by Stephan Witt
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.
* Mac OS X 10.8.5
* Darwin Kernel Version 12.5.0
$ 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
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?
/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
(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)
(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)
(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
(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)
(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)
(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.

Post by Patrick De Visschere

Post by Stephan Witt
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.

Post by Patrick De Visschere

Post by Stephan Witt
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

[Stephan Witt]

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

[Patrick De Visschere]

Post by Stephan Witt

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

[Stephan Witt]

Post by Patrick De Visschere

Post by Stephan Witt

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

[Patrick De Visschere]

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

Post by 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.
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.
#!/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 -framework QtCore -framework QtGui -framework QtWidgets -framework QtMacExtras -framework QtConcurrent"
fi

3) the lyx-build does not find the right iconv library when linking; that may be because of the /opt/local in my PATH; but even with the switch --with-libiconv-prefix=/usr it is still not found.
Therefore I also had to add -L/usr/lib to the LDFLAGS as you can see above.

Patrick

[Stephan Witt]

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

Post by 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.
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.
#!/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.

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.

I don't use --enable-qt5. I've studiedd the configure script and I think it does the wrong thing on a Mac.
On a Mac the Qt libraries are not renamed for Qt5, the core framework is named QtCore and not Qt5Core, e.g.
Perhaps you have to avoid it.

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 -framework QtCore -framework QtGui -framework QtWidgets -framework QtMacExtras -framework QtConcurrent"
fi
3) the lyx-build does not find the right iconv library when linking; that may be because of the /opt/local in my PATH; but even with the switch --with-libiconv-prefix=/usr it is still not found.
Therefore I also had to add -L/usr/lib to the LDFLAGS as you can see above.

That's not nice. Do you have any other component from /opt/local included? aspell, hunspell or libmagic?

Stephan

[Patrick De Visschere]

Post by Stephan Witt

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

Post by 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.
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.
#!/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.

#!/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.

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.

I don't use --enable-qt5. I've studiedd the configure script and I think it does the wrong thing on a Mac.
On a Mac the Qt libraries are not renamed for Qt5, the core framework is named QtCore and not Qt5Core, e.g.
Perhaps you have to avoid it.

Without —enable-qt5 (and the script as it is) I get this error when configuring
checking for QT_CORE... checking for QT_FRONTEND... checking for X... disabled
checking for Qt library name... failed
configure: error: cannot compile a simple Qt executable. Check you have the right $QTDIR.
ERROR: Cannot build and install LyX for x86_64.

When including --enable-qt5 this goes away but still the qt-includes are not found.

Once I modify the scripts as below the --enable-qt5 is not needed anymore.

In the configure.log I find this variable
QT_INCLUDES='-I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/Qt -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/QtCore -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/QtGui -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/QtWidgets -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/QtConcurrent -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/QtMacExtras’

I don’t understand the // in the paths, but the frameworks are not in the include directory.
These paths would make sense if qt was build with -no-framework, which is not the case.

Post by Stephan Witt

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 -framework QtCore -framework QtGui -framework QtWidgets -framework QtMacExtras -framework QtConcurrent"
fi
3) the lyx-build does not find the right iconv library when linking; that may be because of the /opt/local in my PATH; but even with the switch --with-libiconv-prefix=/usr it is still not found.
Therefore I also had to add -L/usr/lib to the LDFLAGS as you can see above.

That's not nice. Do you have any other component from /opt/local included? aspell, hunspell or libmagic?

I build aspell and hunspell with the script and although libmagic is installed (with macports) configure reports that it cannot find magic.h.

Post by Stephan Witt
Stephan

[Stephan Witt]

Post by Patrick De Visschere

Post by Stephan Witt

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

Post by 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.
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.
#!/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.

#!/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.

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.

I don't use --enable-qt5. I've studiedd the configure script and I think it does the wrong thing on a Mac.
On a Mac the Qt libraries are not renamed for Qt5, the core framework is named QtCore and not Qt5Core, e.g.
Perhaps you have to avoid it.

Without —enable-qt5 (and the script as it is) I get this error when configuring
checking for QT_CORE... checking for QT_FRONTEND... checking for X... disabled
checking for Qt library name... failed
configure: error: cannot compile a simple Qt executable. Check you have the right $QTDIR.
ERROR: Cannot build and install LyX for x86_64.
When including --enable-qt5 this goes away but still the qt-includes are not found.
Once I modify the scripts as below the --enable-qt5 is not needed anymore.
In the configure.log I find this variable
QT_INCLUDES='-I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/Qt -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/QtCore -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/QtGui -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/QtWidgets -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/QtConcurrent -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/QtMacExtras’
I don’t understand the // in the paths, but the frameworks are not in the include directory.

They don't hurt. I'd guess the paths are constructed and somewhere the slashes are added twice "to be sure".

Post by Patrick De Visschere
These paths would make sense if qt was build with -no-framework, which is not the case.

This is the successful conftest command from my configure log:
configure:9758: c++ -o conftest -Os -I/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//include -I/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//include/Qt -I/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//include/QtCore -I/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//include/QtGui -I/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//include/QtWidgets -I/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//include/QtConcurrent -I/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//include/QtMacExtras -F/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//lib -I/Users/Shared/LyX/utilities/include -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -arch x86_64 -mmacosx-version-min=10.6 -L/Users/Shared/LyX/utilities/lib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -arch x86_64 -mmacosx-version-min=10.6 conftest.cpp -liconv -lz -lmagic -framework QtCore -framework QtConcurrent -framework QtWidgets -framework QtMacExtras -framework QtGui

For the link step with frameworks the "-F/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//lib" switch is essential, IMO.

Stephan

[Patrick De Visschere]

Sent from my iPad

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

Post by Stephan Witt

Post by Patrick De Visschere

Post by Stephan Witt

Post by 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.
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.
#!/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.

#!/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.

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.

I don't use --enable-qt5. I've studiedd the configure script and I think it does the wrong thing on a Mac.
On a Mac the Qt libraries are not renamed for Qt5, the core framework is named QtCore and not Qt5Core, e.g.
Perhaps you have to avoid it.

Without —enable-qt5 (and the script as it is) I get this error when configuring
checking for QT_CORE... checking for QT_FRONTEND... checking for X... disabled
checking for Qt library name... failed
configure: error: cannot compile a simple Qt executable. Check you have the right $QTDIR.
ERROR: Cannot build and install LyX for x86_64.
When including --enable-qt5 this goes away but still the qt-includes are not found.
Once I modify the scripts as below the --enable-qt5 is not needed anymore.
In the configure.log I find this variable
QT_INCLUDES='-I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/Qt -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/QtCore -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/QtGui -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/QtWidgets -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/QtConcurrent -I/Users/pdv/Developer/public/Trolltech/Qt-5.3.1//include/QtMacExtras’
I don’t understand the // in the paths, but the frameworks are not in the include directory.

They don't hurt. I'd guess the paths are constructed and somewhere the slashes are added twice "to be sure".

Post by Patrick De Visschere
These paths would make sense if qt was build with -no-framework, which is not the case.

configure:9758: c++ -o conftest -Os -I/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//include -I/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//include/Qt -I/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//include/QtCore -I/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//include/QtGui -I/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//include/QtWidgets -I/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//include/QtConcurrent -I/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//include/QtMacExtras -F/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//lib -I/Users/Shared/LyX/utilities/include -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -arch x86_64 -mmacosx-version-min=10.6 -L/Users/Shared/LyX/utilities/lib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -arch x86_64 -mmacosx-version-min=10.6 conftest.cpp -liconv -lz -lmagic -framework QtCore -framework QtConcurrent -framework QtWidgets -framework QtMacExtras -framework QtGui
For the link step with frameworks the "-F/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64//lib" switch is essential, IMO.
Stephan

Stephan,

I'm beginning to think that we must have different qt-installs. Although the -F switch suggests mac-frameworks, the header files are then not to be found in an include directory, but e.g. in .../lib/QtCore.framework/Headers, that is if qt has been installed as a framework, as I've done. The -I paths mentioned make sense for a normal (non-framework) install. I have always assumed that a framework installation is required but maybe the build script can build the frameworks from a normal install. I cannot check this right now.

Patrick

[Stephan Witt]

Post by Stephan Witt

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