Created attachment 519 [details] screenshot of open gl qt visualiser on mojave With the recent mac OS Mojave (OSX 10.14) the parts of the OpenGL QT visualiser become huge and overlap making it unusable - see attached screenshot. The command terminal and icons cannot be used. The command terminal and actual visualisation sub-frames appear to be normal sized, but the scene tree and the icon bar at the top appear to be huge (maybe double size). Reproduced on two new macbook pros with Qt 5.11.2 from macports and Geant4.10.4.p02. Searching online, I find many bugs reported related to dark mode, but this wasn't used in either case. You can reproduce this with the above mentioned version of Qt on mac OS latest mojave with the B1 basic example 4.10.4.p02.
Created attachment 520 [details] same visualisation on earlier version of mac OS (el capitan) with same qt and Geant4
Hi Laurie. I've not yet upgraded to Mojave but https://blog.qt.io/blog/2018/11/08/qt-macos-10-14-mojave/ suggests you need Qt 5.12 and, presumably, the latest Xcode. Are you in a position to try that?
Hello John, Thanks for the quick reply. We're trying with Qt5.12 just now. I also haven't upgraded my own mac (and will hold off), but we're trying on another new mac in our group that has it. I'll report back shortly and also note the xcode version. Cheers, Laurie
Hello again, We were able to get a normal visualiser window with the following (from my colleague Stewart): 1) Qt 5.12 built from source using Xcode 9.4.1 (SDK 10.13.4) 2) Down load Xcode from https://developer.apple.com/download/more/ 3) copy Xcode to /Applications/Xcode_9.4.1 4) sudo xcode-select --switch /Applications/Xcode_9.4.1.app 5) Compile and install Qt 5.12 6) Compile G4 application against this Qt5.12 This was based on: https://blog.qt.io/blog/2018/11/08/qt-macos-10-14-mojave/ https://doc-snapshots.qt.io/qt5-5.12/macos.html https://en.m.wikipedia.org/wiki/Xcode (for SDK versions) So the xcode had to be downgraded for it to work. The build version of our application worked, but the install did not as the rpath was missing for Qt. We've never had to explicitly add the rpath for the Qt libraries before - not sure if this is on the Qt side or the libG4OpenGL side. We were able to fix the installed executable with: install_name_tool -add_rpath /Users/sboogert/Local/qt5/install/lib/ /Users/sboogert/Physics/codeinsta/mos/bin/bdsim If we use otool -L on our application shared library - for Qt5.11 on Mac OS El Capitan, we have (for example): /opt/local/libexec/qt5/lib/QtGui.framework/Versions/5/QtGui (compatibility version 5.11.0, current version 5.11.2) and for the above described setup on Mojave with 5.12 we have: @rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.12.0, current version 5.12.0) In our cmake for our application we do: set(CMAKE_INSTALL_RPATH "${Geant4_LIBRARY_DIR};${CMAKE_INSTALL_PREFIX}/lib") So perhaps there is a change to their use of rpaths. Qt5.12 is due to be released on ~5th December it would seem: https://wiki.qt.io/Qt_5.12_Release What do you think? It looks like this may be resolved by Qt5.12 rather than something implementation-wise on the Geant4 side. However, there may be an issue with rpaths. Best, Laurie
Created attachment 521 [details] screenshot of visualiser working on mojave
Really great, Laurie. Thankyou for this. This is vital information for the upcoming release of Geant4. I hope we can make it happen.
Hi Laurie, I've upgrade myself on MacBook Pro mid-2016 + Mojave (10.14.1) + XCode10 + Geant4.10.4.p02, I've try the following configurations : - XCode 10 + Qt5.10 => OK - XCode 10 + Qt5.11.2 => OK As you've wrote, Qt5.12 should fix a couple of things for Mojave (https://blog.qt.io/blog/2018/11/08/qt-macos-10-14-mojave/) I have to test with XCode9.4.1. > The build version of our application worked, but the install did not as the > rpath was missing for Qt. We've never had to explicitly add the rpath for the > Qt libraries before - not sure if this is on the Qt side or the libG4OpenGL > side. We were able to fix the installed executable with: About rpath, as Qt5.12 is a beta version, perhaps they'll fix it. Many thanks for your feedback Laurent
Hum... I was on XCode 10 beta, I've upgrade to XCode10.1 + Qt5.12 and I've got the same bad result as you :( No clue except as you said, downgrade XCode version Laurent
Hi All, thanks for the investigation. This problem was driving me crazy. I can confirm that downgrading the version of Xcode produces a usable visualise. I have Qt5.12 installed (this is the framework installed from their website, I didn't compile it myself), Xcode9.4.1, and running OSX 10.14. This works fine and produces a usable visualise but upgrading to Xcode 10.1 and I get the above problems with the visualise. Cheers, Paul
Created attachment 529 [details] exampleB2b on Mojave, Xcode 10.1 and Qt 5.12 With Qt 5.12 released recently, the zoomed Qt GUI issue (MacOS 10.14.2, XCode 10.1) seems solved. The GL scene however disappears completely and no scene tree is showed (see picture exampleB2b_Qt attached)
Yes, I guess Qt5.12 did not solve anything (see release notes).I've got the same problem and same issue for scene tree
I also saw the same lack of visualisation with the release 5.12 version of Qt - just grey (following downgraded xcode recipe above). I also still have the same rpath issue where the Qt library path is missing from the geant4 library libG4OpenGL. We can add this to our application as mentioned in a previous comment, but if we add it to the libG4OpenGL library, then all linked applications work without modification. I found these while reading about this if you haven't found them already: https://developer.apple.com/documentation/metal/mixing_metal_and_opengl_rendering_in_a_view https://developer.apple.com/library/archive/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/ToolsOverview/ToolsOverview.html Cheers, Laurie
Created attachment 540 [details] exampleB2b on Mojave, XCode 10.1 and Qt 5.12.1 Upgrading to Qt-5.12.1 problems on MacOS Mojave are solved, Qt/GL displays the scene correctly (see attached screenshot).
Closing ticket.
Hello, Great to see this will be fixed by Qt. I have yet to try this but will in coming weeks. Regarding the rpath issue, I found the cause of this. In our scenario, we had two installations of Qt in separate directories. When we configured a Geant4 build with cmake, we would enter ccmake and turn QT on. It would then automatically find the Qt installation from macports and set ~5 cmake variables visible in ccmake. We would update these in ccmake again to point to the correct working Qt installation in a different directory. Whilst this would compile just fine, there were missing linked libraries are runtime due to the (correct) rpath not being set in the library at compile time. I found that if I configure Geant4 with: cmake ../geant4.10.05 -DGEANT4_USE_QT=ON -DCMAKE_PREFIX_PATH=$QTDIR where $QTDIR is the root directory of the qt install - see here from my profile: export QTDIR=/Users/nevay/physics/packages/qt-everywhere-src-5.12.1-install export PATH=$QTDIR/bin:$PATH this will work correctly with no rpath issues. So changing the cmake variables for Qt is not re-entrant safe or it is such that these could be marked advanced or hidden. The ideal solution would be to have a (possibly) single variable that points to the root of the qt installation. At each configuration, the 5 required variables would be built up from this variable. The 5 variables would also be kept hidden (marked advanced). Currently, there's CLHEP_DIR for example that achieves a similar purpose for CLHEP. Perhaps we could have QT_DIR. I hope this helps, Best, Laurie
