OpenCPN for Mac

[Westerly33]

Originally Posted by CarCode

Furthermore there is no application name attached to the OpenCPN symbol in the "Force Quit Applications" list because the file Info.plist of the OpenCPN bundle is wrong (see your screenshot).
There are so many bugs in the OpenCPN Mac version that the Flyspray will explode to name them all. There are more than 450 faults detected here in the original code...

So, am I better using the Win version? Is there hope the Mac version becomes cleaner?

[nohal]

Originally Posted by CarCode

Furthermore there is no application name attached to the OpenCPN symbol in the "Force Quit Applications" list because the file Info.plist of the OpenCPN bundle is wrong (see your screenshot).
There are so many bugs in the OpenCPN Mac version that the Flyspray will explode to name them all. There are more than 450 faults detected here in the original code...

Gerhard...
Lurking around, I was just wandering if there was something that could not be understood on http://www.cruisersforum.com/forums/...ml#post1185461
Please, if you waste your time here, help us not waste ours.

Thank you very much

Pavel

[bdbcat]

carcode....

If you are interested in improving OpenCPN for Mac, please allow me to suggest the following first steps:

1. Please submit to this forum a corrected Info.plist, a or at least a specific idea of what may be wrong.

2. Please submit to this forum a list or screenshot of "450 faults detected here in the original code"

Thanks
Dave

[CarCode]

1. The Info.plist file is importand for Mac OS X apps. Your current Info.plist file doesn't even show the app name in the Mac OS X environment. Read all about Info.plist here: https://developer.apple.com/library/...roduction.html
A correct Info.plist file is generated automatically by Xcode for you.

2. It was told you have a Mac Mini with Snow Leopard. Get Xcode from App Store, it is for free. Even better to upgrade to Mountain Lion first to get the latest Xcode 4.6.1. Make a Xcode project e.g. with
> mkdir buildXcode
> cd buildXcode
> cmake -DCMAKE_OSX_64=ON -DCMAKE_OSX_DEPLOYMENT_TARGET=10.6 -DCMAKE_C_COMPILER=/usr/bin/gcc -DCMAKE_CXX_COMPILER=/usr/bin/g++ -DPREFIX=/Users/yourHomeName/yourOCPN-Files/buildXcode -G Xcode ..

Start in Xcode "Product/Analyze" and see hundreds of faults like dead code, memory leaks, logic errors, calls to malloc,calloc with 0 bytes, etc. etc.
Here is an example from 2 files only:
src/chart1.cpp:2558:46: Access to field 'm_bFollow' results in a dereference of a null pointer (loaded from variable 'cc1')
src/chart1.cpp:2701:43: Access to field 'm_bFollow' results in a dereference of a null pointer (loaded from variable 'cc1')
src/chart1.cpp:3024:9: Value stored to 'cccw' during its initialization is never read
src/chart1.cpp:3081:44: Called C++ object pointer is null
src/chart1.cpp:3113:5: Called C++ object pointer is null
src/chart1.cpp:4417:5: Called C++ object pointer is null
src/chart1.cpp:4440:5: Called C++ object pointer is null
src/chart1.cpp:4917:23: Value stored to 'style' during its initialization is never read
src/chart1.cpp:4944:23: Value stored to 'style' during its initialization is never read
src/chart1.cpp:5199:5: Called C++ object pointer is null
src/chart1.cpp:5232:9: Called C++ object pointer is null
src/chart1.cpp:5269:16: Value stored to 'proposed_scale_onscreen' during its initialization is never read
src/chart1.cpp:5336:13: Access to field 'm_bFollow' results in a dereference of a null pointer (loaded from variable 'cc1')
src/chart1.cpp:5385:13: Access to field 'm_bFollow' results in a dereference of a null pointer (loaded from variable 'cc1')
src/chart1.cpp:5607:25: Value stored to 'last_nEntry' is never read
src/chart1.cpp:5954:34: Called C++ object pointer is null
src/chart1.cpp:6075:21: Value stored to 'b_success' is never read
src/chart1.cpp:7808:21: Value stored to 'colIdx' is never read
src/chartimg.cpp:627:20: Memory is never released; potential leak of memory pointed to by 'pPlyTable'
src/chartimg.cpp:1668:37: Access to field 'nFwd' results in a dereference of a null pointer
src/chartimg.cpp:1883:9: Value stored to 'iscan' is never read
src/chartimg.cpp:2226:13: Access to field 'pDIBThumb' results in a dereference of a null pointer (loaded from field 'pThumbData')
src/chartimg.cpp:2850:32: The left operand of '-' is a garbage value
src/chartimg.cpp:3204:20: Called C++ object pointer is null
src/chartimg.cpp:3546:23: Called C++ object pointer is null
src/chartimg.cpp:3782:32: The left operand of '-' is a garbage value
src/chartimg.cpp:3966:19: Value stored to 'cr_test' is never read
src/chartimg.cpp:4036:19: Value stored to 'nPixValue' is never read
src/chartimg.cpp:4055:13: Value stored to 'coffset' is never read
src/chartimg.cpp:4342:30: Value stored to 'nlatmax' is never read
src/chartimg.cpp:4342:41: Value stored to 'nlatmin' is never read
src/chartimg.cpp:4368:19: Value stored to 'nlatmin' is never read
src/chartimg.cpp:4374:19: Value stored to 'nlatmax' is never read
src/chartimg.cpp:4415:31: Value stored to 'nlatmin' is never read
src/chartimg.cpp:4421:31: Value stored to 'nlatmax' is never read
src/chartimg.cpp:4615:20: Value stored to 'lata' is never read
src/chartimg.cpp:4616:20: Value stored to 'lona' is never read
src/chartimg.cpp:4723:15: Value stored to 'xpl_err_max_meters' is never read
src/chartimg.cpp:4724:15: Value stored to 'ypl_err_max_meters' is never read
src/chartimg.cpp:4787:21: Value stored to 'xpl_err_max_meters' is never read
src/chartimg.cpp:4788:21: Value stored to 'ypl_err_max_meters' is never read

BTW there is no difference between 64-bit and 32-bit of such items. Mac machines are 64-bit however.

Gerhard

[nohal]

Gerhard...
Sorry, I have no Mac of whichever type, so can't satisfy myself - XCode reports 450 harmless warnings and obviously mostly false positive potential errors from it's static code analysis, or is your statement about 450 errors actually based on some analysis of the output?

Thanks you

Pavel

[bdbcat]

gerhard....

I will run the xCode as you suggest. Thanks for the info.

Just for fun, though, I took a look at some of the warnings listed in your post. Maybe I do not understand the compiler's analysis methods. Take a look at this one:

src/chart1.cpp:5269:16: Value stored to 'proposed_scale_onscreen' during its initialization is never read

Here is the code.

double MyFrame::GetBestVPScale( ChartBase *pchart )
{
    if( pchart ) {
        double proposed_scale_onscreen = cc1->GetCanvasScaleFactor() / cc1->GetVPScale();

        if( ( g_bPreserveScaleOnX ) || ( CHART_TYPE_CM93COMP == pchart->GetChartType() ) ) {
            double new_scale_ppm = pchart->GetNearestPreferredScalePPM( cc1->GetVPScale() );
            proposed_scale_onscreen = cc1->GetCanvasScaleFactor() / new_scale_ppm;
        } else {
            //  This logic will bring the new chart onscreen at roughly twice the true paper scale equivalent.
            proposed_scale_onscreen = pchart->GetNativeScale() / 2;
            double equivalent_vp_scale = cc1->GetCanvasScaleFactor() / proposed_scale_onscreen;
            double new_scale_ppm = pchart->GetNearestPreferredScalePPM( equivalent_vp_scale );
            proposed_scale_onscreen = cc1->GetCanvasScaleFactor() / new_scale_ppm;
        }

        proposed_scale_onscreen =
                wxMin(proposed_scale_onscreen, pchart->GetNormalScaleMax(cc1->GetCanvasScaleFactor(), cc1->GetCanvasWidth()));
        proposed_scale_onscreen =
                wxMax(proposed_scale_onscreen, pchart->GetNormalScaleMin(cc1->GetCanvasScaleFactor(), g_b_overzoom_x));

        return cc1->GetCanvasScaleFactor() / proposed_scale_onscreen;
    } else
        return 1.0;
}

I cannot see how one could conclude that "proposed_scale_onscreen" is never read. I see it right there...

return cc1->GetCanvasScaleFactor() / proposed_scale_onscreen;

This makes me suspicious of the analysis....

But anyway, I'll take a look at some more of the warnings and see if there are any that could become run-time errors.

Thanks again
Dave

[CarinaPDX]

Hi Dave-

While you're looking at the Mac build, could you please review my post #41 on the OpenCPN 3.2.0 Released thread? There were only a handful of build problems. I am particularly interested in fixing the problems that prevented the plug-ins from getting installed. It appears that the enclosing folders were an absolute reference from your machine, and not a relative reference based on the build location.

I am suspicious that the default error checking is different (less restrictive) for Snow Leopard's Xcode vs. later versions. (I have Snow Leopard 10.6.8) Once the addressing folder problems are fixed I'll try another build with more error checking if possible.

Thanks as always,

Greg

[Viking Sailor]

Originally Posted by bdbcat

gerhard....

I will run the xCode as you suggest. Thanks for the info.

Just for fun, though, I took a look at some of the warnings listed in your post. Maybe I do not understand the compiler's analysis methods. Take a look at this one:

src/chart1.cpp:5269:16: Value stored to 'proposed_scale_onscreen' during its initialization is never read

Here is the code.

double MyFrame::GetBestVPScale( ChartBase *pchart )
{
    if( pchart ) {
        double proposed_scale_onscreen = cc1->GetCanvasScaleFactor() / cc1->GetVPScale();

        if( ( g_bPreserveScaleOnX ) || ( CHART_TYPE_CM93COMP == pchart->GetChartType() ) ) {
            double new_scale_ppm = pchart->GetNearestPreferredScalePPM( cc1->GetVPScale() );
            proposed_scale_onscreen = cc1->GetCanvasScaleFactor() / new_scale_ppm;
        } else {
            //  This logic will bring the new chart onscreen at roughly twice the true paper scale equivalent.
            proposed_scale_onscreen = pchart->GetNativeScale() / 2;
            double equivalent_vp_scale = cc1->GetCanvasScaleFactor() / proposed_scale_onscreen;
            double new_scale_ppm = pchart->GetNearestPreferredScalePPM( equivalent_vp_scale );
            proposed_scale_onscreen = cc1->GetCanvasScaleFactor() / new_scale_ppm;
        }

        proposed_scale_onscreen =
                wxMin(proposed_scale_onscreen, pchart->GetNormalScaleMax(cc1->GetCanvasScaleFactor(), cc1->GetCanvasWidth()));
        proposed_scale_onscreen =
                wxMax(proposed_scale_onscreen, pchart->GetNormalScaleMin(cc1->GetCanvasScaleFactor(), g_b_overzoom_x));

        return cc1->GetCanvasScaleFactor() / proposed_scale_onscreen;
    } else
        return 1.0;
}

I cannot see how one could conclude that "proposed_scale_onscreen" is never read. I see it right there...

return cc1->GetCanvasScaleFactor() / proposed_scale_onscreen;

This makes me suspicious of the analysis....

But anyway, I'll take a look at some more of the warnings and see if there are any that could become run-time errors.

Thanks again
Dave

Hi Dave,

You declare and set "proposed_scale_onscreen" inside the first conditional statement. You then set It again in both the true and false parts of the next conditional statement before referencing it.

The setting of "proposed_scale_onscreen" in the two statements prior to the return statement looks a little strange but could be OK.

Best regards,

Paul

[sbfreddie]

Originally Posted by CarinaPDX

Hi Dave-

While you're looking at the Mac build, could you please review my post #41 on the OpenCPN 3.2.0 Released thread? There were only a handful of build problems. I am particularly interested in fixing the problems that prevented the plug-ins from getting installed. It appears that the enclosing folders were an absolute reference from your machine, and not a relative reference based on the build location.

I am suspicious that the default error checking is different (less restrictive) for Snow Leopard's Xcode vs. later versions. (I have Snow Leopard 10.6.8) Once the addressing folder problems are fixed I'll try another build with more error checking if possible.

Thanks as always,

Greg

Greg:
Hi, I'm Freddie and I've also been working on the Mac Version for quite some time.
I have found the answer to your query about the building of the plugins.
Look in the plugins folder in lets say the first plugin called Dashboard_pi "CMakeLists.txt" file and you will find this at approx line # 182:

IF(APPLE)
      INSTALL(TARGETS ${PACKAGE_NAME} BUNDLE LIBRARY DESTINATION ${CMAKE_BINARY_DIR}/OpenCPN.app/Contents/PlugIns)
ENDIF(APPLE)

As you can see Cmake is putting the plugin in the ${CMAKE_BINARY_DIR} which is not defined anywhere in the top-level CMakeLists.txt so CMake puts it in the default directory which is the directory where it is being built.

Also at Line # 248 you will find this:

IF(APPLE)
      INSTALL(FILES ${_gmoFile} DESTINATION ${CMAKE_INSTALL_PREFIX}/bin/OpenCPN.app/Contents/Resources/${_poBasename}.lproj RENAME opencpn-${PACKAGE_NAME}.mo )
ELSE(APPLE)
      INSTALL(FILES ${_gmoFile} DESTINATION ${PREFIX_DATA}/locale/${_poBasename}/LC_MESSAGES RENAME opencpn-${PACKAGE_NAME}.mo )
ENDIF(APPLE)

Here you find that CMake is told to put the po files in another directory called "${CMAKE_INSTALL_PREFIX}/bin", so CMake is building two different OpenCPN.apps one in the ${CMAKE_BINARY_DIR} (which is not defined) and another in ${CMAKE_INSTALL_PREFIX}/bin which is defined if you tell it at the command line.

But wait! there is more.

Back in the CMakeLists.txt for the Main build at lines 709 - 778 you will find this code:

IF(APPLE)

SET_SOURCE_FILES_PROPERTIES(
           ${gshhs} PROPERTIES MACOSX_PACKAGE_LOCATION SharedSupport/gshhs  )
SET_SOURCE_FILES_PROPERTIES(
           ${uiData} PROPERTIES MACOSX_PACKAGE_LOCATION SharedSupport/uidata  )
SET_SOURCE_FILES_PROPERTIES(
           ${s57data} PROPERTIES MACOSX_PACKAGE_LOCATION SharedSupport/s57data  )
SET_SOURCE_FILES_PROPERTIES(
           ${tcData} PROPERTIES MACOSX_PACKAGE_LOCATION SharedSupport/tcdata  )
SET_SOURCE_FILES_PROPERTIES(
           data/license.txt PROPERTIES MACOSX_PACKAGE_LOCATION SharedSupport )

FILE(GLOB SOUND_FILES ${CMAKE_SOURCE_DIR}/data/sounds/*)
FOREACH (_currentSoundFile ${SOUND_FILES})
  SET_SOURCE_FILES_PROPERTIES(
           ${_currentSoundFile} PROPERTIES MACOSX_PACKAGE_LOCATION SharedSupport/sounds )
ENDFOREACH (_currentSoundFile )

SET_SOURCE_FILES_PROPERTIES(
           data/doc/help_web.html PROPERTIES MACOSX_PACKAGE_LOCATION SharedSupport/doc )

SET_SOURCE_FILES_PROPERTIES(
           data/doc/help_en_US.html PROPERTIES MACOSX_PACKAGE_LOCATION SharedSupport/doc )

FILE(GLOB DOC_FILES "${CMAKE_SOURCE_DIR}/data/doc/OpenCPN User Manual_files/*")
FOREACH (_currentDocFile ${DOC_FILES})
  SET_SOURCE_FILES_PROPERTIES(
           ${_currentDocFile}
           PROPERTIES MACOSX_PACKAGE_LOCATION "SharedSupport/doc/OpenCPN User Manual_files" )
ENDFOREACH (_currentDocFile )

SET_SOURCE_FILES_PROPERTIES(
           buildosx/opencpn.icns PROPERTIES MACOSX_PACKAGE_LOCATION Resources )

SET_SOURCE_FILES_PROPERTIES(
           buildosx/MainMenu.xib PROPERTIES MACOSX_PACKAGE_LOCATION Resources/English.lproj )

SET(MACOSX_BUNDLE_ICON_FILE opencpn.icns)

ADD_EXECUTABLE(${PACKAGE_NAME} MACOSX_BUNDLE
      ${HDRS}
      ${SRCS}
      ${gshhs}
      ${uiData}
      ${s57data}
      ${tcData}
      data/license.txt
      ${SOUND_FILES}
      data/doc/help_web.html
      data/doc/help_en_US.html
      ${DOC_FILES}
      buildosx/opencpn.icns
      buildosx/MainMenu.xib
      )


  INSTALL(TARGETS
    ${PACKAGE_NAME}
    BUNDLE DESTINATION ${PREFIX_BIN} PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE)


TARGET_LINK_LIBRARIES(${PACKAGE_NAME}
      ${wxWidgets_LIBRARIES}
      NMEA0183
      ${EXTRA_LIBS}
      )


ENDIF(APPLE)

Do you see this variable:
"MACOSX_PACKAGE_LOCATION"
its also not defined anywhere so CMake just puts it wherever the default location is.
Also the BUNDLE DESTINATION ${PREFIX_BIN} is somewhere else so this is why there is a mixup in the Mac build occurs.

That why the build thats located in the "bin" directory has no plugins, they are in the parallel build in the main build directory, if you look you see it there. But you cannot just take them from one and move to another because of the code located at 1135 - 1164 which does the CMake fixup_bundle magic:

INCLUDE(CPack)

IF(APPLE)
# -- Run the BundleUtilities cmake code
  SET(CPACK_BUNDLE_PLIST "${CMAKE_SOURCE_DIR}/buildosx/Info.plist")

  SET(APPS "\${CMAKE_INSTALL_PREFIX}/bin/OpenCPN.app")
  SET(DIRS "")

  SET(LIBS "\${CMAKE_INSTALL_PREFIX}/bin/OpenCPN.app/Contents/PlugIns/libdashboard_pi.dylib")
  SET(LIBS
      ${LIBS} "\${CMAKE_INSTALL_PREFIX}/bin/OpenCPN.app/Contents/PlugIns/libgrib_pi.dylib")

  INSTALL(CODE "
   include(BundleUtilities)
   fixup_bundle(\"${APPS}\"   \"${LIBS}\"   \"${DIRS}\")
   " COMPONENT Runtime)

 ADD_CUSTOM_COMMAND(
   OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${PACKAGE_NAME}_${VERSION_MAJOR}.${VERSION_MINOR}.${VERSION_PATCH}.dmg
   COMMAND ${CMAKE_SOURCE_DIR}/buildosx/create-dmg ${CMAKE_CURRENT_BINARY_DIR}/${PACKAGE_NAME}_${VERSION_MAJOR}.${VERSION_MINOR}.${VERSION_PATCH}.dmg ${CMAKE_INSTALL_PREFIX}/bin/
   DEPENDS ${CMAKE_INSTALL_PREFIX}/bin/OpenCPN.app
   WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
   COMMENT "create-dmg [${PACKAGE_NAME}]: Generated dmg file."
)

 ADD_CUSTOM_TARGET(create-dmg COMMENT "create-dmg: Done." DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${PACKAGE_NAME}_${VERSION_MAJOR}.${VERSION_MINOR}.${VERSION_PATCH}.dmg)


ENDIF(APPLE)

Do you see the same confusion regarding the location of the source and destination bundles.

Now you can see the problem for the lack of plugins in the /bin/OpenPCN.app bundle.

Sorry for the long post.
Thanks,
Freddie

[CarinaPDX]

Thanks Freddie!

You are waaay ahead of me on this one. Can you recommend patches that can fix the problem?

I am trying to build for 32 bit Carbon on Intel (Wx 2.8.x). Once I get that process working I might try to extend back to 10.4u (universal Intel + PPC). That would take a bit of work as I would have to rebuild all of my MacPorts dependencies to include PPC code (right now "universal"= Intel 32 + 64). There has been some demand for the PPC version so I would give it a try. If it didn't work there isn't a lot I could do about it, but worth the effort I think.

Gerhard is working on a build for 64 bit Cocoa on Intel (Wx 2.9.x). This is the future (well, really the present) but 2.9 is still basically a beta release for Cocoa support in Wx 3.0, so there may be problems that are beyond OCPN to fix. I hope he does succeed soon - it just is a bit on the bleeding edge.

Greg

[CarCode]

Another hint is to use the Profiler tool in Xcode. It helps to find out time critical code and in some cases I got with help of Profiler a former 99% CPU usage down to 3.6%. Give it a try so...

[Scratch]

I am unable to make any audible alarms work. Is there something I'm doing wrong? This is literally the only feature that is missing for me and I'm sure that it is an easy fix that I'm missing. Any help would be much appreciated.

Scratch

[CarCode]

You may want to tell us which OpenCPN version you are using and which Mac device and OS version.
I do not have any problems with sound using OpenCPN 3.3.1006, MacBookPro and OS X 10.9.

Gerhard

[tinpusher]

Originally Posted by Westerly33

Version 3.2 on my mac book not responding every time I click on eye icon in the rout manger. I have to restart the program.

Me too, did you find an answer?

[rumtum]

I have new mac 10.9.1 Leopard, snow leopard,, have no idea. But I do see under system info hardware the term Thunderbolt Bus.
I have been using open con on the old pc unit and its great. Want to get it set up on the Mac Suggestions