Same root cause as the earlier Windows exe icon issue: add_executable() never set MACOSX_BUNDLE, so the macOS build produced a bare Mach-O binary rather than a proper .app bundle. Without a bundle there's no Info.plist/.icns mechanism at all for Finder to show a custom icon.
Fixed across three commits:
ac3cebc: added packaging/macos/orbithub.icns (rendered up to 1024px from the same createOrbitHubAppIcon() logic used at runtime) and wired MACOSX_BUNDLE + MACOSX_BUNDLE_ICON_FILE into CMake. Build output moves from build/orbithub to build/orbithub.app (launch with open build/orbithub.app); docs/BUILDING.md updated.
49ee12f: fixed a CMake configure error (install(TARGETS) needs an explicit BUNDLE DESTINATION for a MACOSX_BUNDLE target).
9d88b74: the first .icns (written via Pillow) didn't actually render in Finder (showed the generic "unavailable" placeholder) -- rebuilt by hand using Apple's documented icns binary format directly instead of relying on Pillow's ICNS encoder.
None of this affects where existing profiles/database live, since that uses QStandardPaths::AppDataLocation, not the executable's own path. Confirmed fixed: .app bundle builds and shows the correct icon in Finder.
Same root cause as the earlier Windows exe icon issue: `add_executable()` never set `MACOSX_BUNDLE`, so the macOS build produced a bare Mach-O binary rather than a proper `.app` bundle. Without a bundle there's no `Info.plist`/`.icns` mechanism at all for Finder to show a custom icon.
Fixed across three commits:
- ac3cebc: added `packaging/macos/orbithub.icns` (rendered up to 1024px from the same `createOrbitHubAppIcon()` logic used at runtime) and wired `MACOSX_BUNDLE` + `MACOSX_BUNDLE_ICON_FILE` into CMake. Build output moves from `build/orbithub` to `build/orbithub.app` (launch with `open build/orbithub.app`); docs/BUILDING.md updated.
- 49ee12f: fixed a CMake configure error (`install(TARGETS)` needs an explicit `BUNDLE DESTINATION` for a `MACOSX_BUNDLE` target).
- 9d88b74: the first `.icns` (written via Pillow) didn't actually render in Finder (showed the generic "unavailable" placeholder) -- rebuilt by hand using Apple's documented icns binary format directly instead of relying on Pillow's ICNS encoder.
None of this affects where existing profiles/database live, since that uses `QStandardPaths::AppDataLocation`, not the executable's own path. Confirmed fixed: `.app` bundle builds and shows the correct icon in Finder.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Same root cause as the earlier Windows exe icon issue:
add_executable()never setMACOSX_BUNDLE, so the macOS build produced a bare Mach-O binary rather than a proper.appbundle. Without a bundle there's noInfo.plist/.icnsmechanism at all for Finder to show a custom icon.Fixed across three commits:
ac3cebc: addedpackaging/macos/orbithub.icns(rendered up to 1024px from the samecreateOrbitHubAppIcon()logic used at runtime) and wiredMACOSX_BUNDLE+MACOSX_BUNDLE_ICON_FILEinto CMake. Build output moves frombuild/orbithubtobuild/orbithub.app(launch withopen build/orbithub.app); docs/BUILDING.md updated.49ee12f: fixed a CMake configure error (install(TARGETS)needs an explicitBUNDLE DESTINATIONfor aMACOSX_BUNDLEtarget).9d88b74: the first.icns(written via Pillow) didn't actually render in Finder (showed the generic "unavailable" placeholder) -- rebuilt by hand using Apple's documented icns binary format directly instead of relying on Pillow's ICNS encoder.None of this affects where existing profiles/database live, since that uses
QStandardPaths::AppDataLocation, not the executable's own path. Confirmed fixed:.appbundle builds and shows the correct icon in Finder.