Inconsistency between organization name used for settings files and for macOS bundle identifier

There are inconsistencies between the organization associated with the settings file location and the value set as macOS bundle identifier.

Settings file location macOS bundle identifier

These correspond to the default values associated with the following variables:

CMake variable Default value
Slicer_ORGANIZATION_NAME NA-MIC[1]
Slicer_ORGANIZATION_DOMAIN www.na-mic.org [2]
Slicer_MACOSX_BUNDLE_GUI_IDENTIFIER org.slicer.slicer[3]

Question: Should we update the value of Slicer_ORGANIZATION_NAME and Slicer_ORGANIZATION_DOMAIN to respectively be Slicer and www.slicer.org (slicer.org) ?


  1. https://github.com/Slicer/Slicer/blob/v5.2.1/CMake/SlicerApplicationOptions.cmake#L67 ↩︎

  2. https://github.com/Slicer/Slicer/blob/v5.2.1/CMake/SlicerApplicationOptions.cmake#L60 ↩︎

  3. https://github.com/Slicer/Slicer/blob/v5.2.1/CMake/SlicerApplicationOptions.cmake#L126 ↩︎

Yes, using Slicer as the organization makes sense. I was recently helping a user find the settings file in AppData and they had trouble finding it because it wasn’t immediately obvious that Slicer was under a NA-MIC organization directory.

I think the only remaining activity of the NA-MIC organization is the Project Week (https://projectweek.na-mic.org/), but I think even that is only a label that is attached to the group of organizers. So, it would be probably more accurate to say that today Slicer is developed by the Slicer community (www.slicer.org) and not the NA-MIC community (www.na-mic.org) and we could reflect that by changing the organization name/domain on all platforms.

Yes, I think that using Slicer consistently would be more logical. It’s always been weird that the config paths on mac and linux aren’t consistent so clearing that up too would be nice.

To follow up on this:

1 Like