Files
multica/apps/desktop/electron-builder.yml
Bohan Jiang 26924dcc98 fix(desktop): restore Multica icon + WM_CLASS on Linux (MUL-2145) (#2525)
Closes the regression reported in https://github.com/multica-ai/multica/issues/2515 that
PR #2437 only half-fixed in v0.2.31.

Two gaps remained on Ubuntu/GNOME:

1. The .deb shipped only the source 1024×1024 PNG under
   /usr/share/icons/hicolor/, with no usable smaller sizes. GNOME's hicolor
   lookup walks 16…512 and falls back to the theme default when none
   match, so the launcher had no icon. The auto-generation pass in
   electron-builder silently produced only the source size for us. Drop
   pre-rendered 16/24/32/48/64/128/256/512 PNGs into build/icons/ and
   point `linux.icon` at the directory so packaging stops depending on
   the toolchain re-running that generation correctly.

2. WM_CLASS at runtime was `@multica/desktop`, while the .desktop file
   declared `StartupWMClass=Multica`. PR #2437 assumed Electron derives
   WM_CLASS from electron-builder.yml's `productName`, but Electron
   reads `app.getName()`, which reads the *packaged ASAR's* package.json
   — productName if present, otherwise name. Our source
   apps/desktop/package.json had no top-level productName, so the ASAR
   carried only `name: "@multica/desktop"` and Chromium emitted that as
   WM_CLASS, breaking the .desktop association and the dock icon.

   Fixed in two anchors for belt-and-braces: add
   `"productName": "Multica"` to apps/desktop/package.json (so the ASAR
   carries it and app.getName() resolves correctly by default), and call
   `app.setName("Multica")` in the production branch alongside the
   existing dev-only setName so a future regression in package.json or
   the build pipeline cannot silently re-break WM_CLASS.

The `StartupWMClass: Multica` declaration in electron-builder.yml stays
pinned and the surrounding comment has been rewritten to record the
correct WM_CLASS derivation.

Verification on a real Ubuntu install:
- `dpkg-deb -c multica-desktop-*-linux-amd64.deb | grep hicolor` lists
  ≥8 sizes.
- `xprop WM_CLASS` on the running window prints `"multica", "Multica"`.
- Launcher and dock both show the Multica logo with no manual
  ~/.local/share/icons workaround.

Co-authored-by: multica-agent <github@multica.ai>
2026-05-13 17:31:52 +08:00

102 lines
4.6 KiB
YAML
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
appId: ai.multica.desktop
productName: Multica
directories:
buildResources: build
files:
- "!**/.vscode/*"
- "!src/*"
- "!electron.vite.config.*"
- "!{.eslintignore,.eslintrc.cjs,.prettierignore,.prettierrc.yaml,dev-app-update.yml,CHANGELOG.md,README.md}"
- "!{tsconfig.json,tsconfig.node.json,tsconfig.web.json}"
protocols:
- name: Multica
schemes:
- multica
asarUnpack:
- resources/**
mac:
entitlementsInherit: build/entitlements.mac.plist
target:
- dmg
- zip
# Hardcoded name avoids the `@multica/desktop-*` subdirectory that
# `${name}` produces for scoped package names.
# Naming scheme: multica-desktop-<version>-<platform>-<arch>.<ext>
# so the filename alone surfaces kind, version, platform, and CPU arch.
artifactName: multica-desktop-${version}-mac-${arch}.${ext}
# Notarize via notarytool. Requires APPLE_ID + APPLE_APP_SPECIFIC_PASSWORD
# + APPLE_TEAM_ID env vars at package time. Non-mac contributors are
# unaffected because `pnpm package` already requires the Developer ID
# signing cert — notarization is a strict superset.
notarize: true
dmg:
artifactName: multica-desktop-${version}-mac-${arch}.${ext}
linux:
# Override the Linux executable name to avoid leaking the scoped npm
# package name (`@multica/desktop`) into the installed binary, the
# `.desktop` file, and the hicolor icon filename. Without this override
# electron-builder defaults `executableName` to the package `name`,
# which after slash-stripping becomes `@multicadesktop` — producing
# `/usr/share/applications/@multicadesktop.desktop`,
# `Icon=@multicadesktop`, and
# `/usr/share/icons/hicolor/*/apps/@multicadesktop.png`. The leading `@`
# violates the freedesktop desktop-entry naming guidance, so GNOME /
# Ubuntu fail to associate the running window with the `.desktop` entry
# and fall back to the theme's default app icon (the Settings gear on
# Yaru). Forcing `multica` makes every Linux identity slot agree and
# matches `StartupWMClass=Multica` (productName-derived).
executableName: multica
# Pin StartupWMClass to the WM_CLASS Electron emits on X11. Electron
# derives WM_CLASS from `app.getName()`, which reads the *packaged*
# ASAR's `package.json` — `productName` if present, otherwise `name`.
# PR #2437 assumed electron-builder.yml's productName fed app.getName()
# directly; it does not. With our source package.json carrying only
# `name: "@multica/desktop"`, packaged Electron emitted
# `WM_CLASS=@multica/desktop`, which broke association with this entry
# and reproduced #2515 on Ubuntu 0.2.31. The fix lives in two places
# outside this file — `productName: "Multica"` on the source
# package.json (so the ASAR carries it) and `app.setName("Multica")`
# in the production branch of `src/main/index.ts` (belt-and-braces).
# Keep `StartupWMClass: Multica` pinned here so any future drift in
# those two anchors shows up as a diff against this declaration.
# Verification on a real Ubuntu install: `xprop WM_CLASS` on a running
# window prints `Multica` for both fields.
desktop:
entry:
StartupWMClass: Multica
# Point at pre-rendered hicolor sizes. electron-builder *can* generate
# 16/24/32/48/64/128/256/512 from a single build/icon.png, but the
# auto-generation silently shipped only the 1024×1024 source in our
# v0.2.31 .deb (#2515 reproduces this) — leaving GNOME's hicolor lookup
# with no usable size and falling back to the theme default. Shipping
# the sizes from source removes the toolchain dependency entirely.
icon: build/icons
target:
- AppImage
- deb
- rpm
artifactName: multica-desktop-${version}-linux-${arch}.${ext}
rpm:
# Disable RPM build-id symlinks. Electron apps embed the upstream Electron
# binary, whose GNU build-id is identical across every app shipping the same
# Electron version (Slack, VS Code, Discord, ...). Without this, our RPM
# would own /usr/lib/.build-id/<hash> paths and collide with any other
# Electron RPM already installed, breaking `dnf install` on Fedora/RHEL.
fpm:
- "--rpm-rpmbuild-define=_build_id_links none"
win:
target:
- nsis
artifactName: multica-desktop-${version}-windows-${arch}.${ext}
publish:
provider: github
owner: multica-ai
repo: multica
# Align with our CLI release flow which pre-creates a *published* GitHub
# Release via `gh release create`. The electron-builder default of
# `releaseType: draft` conflicts with `existingType=release` and causes
# uploads of the DMG/ZIP/blockmaps/latest-mac.yml to be silently skipped,
# which breaks electron-updater auto-update on installed clients.
releaseType: release
npmRebuild: false