mirror of
https://github.com/multica-ai/multica.git
synced 2026-06-17 03:38:32 +02:00
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>
102 lines
4.6 KiB
YAML
102 lines
4.6 KiB
YAML
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
|