Commit Graph

4 Commits

Author SHA1 Message Date
Michael Bradley, Jr 05f38fa966 chore: refactor prod/dev app icon and related logic for macOS 2021-01-15 19:12:42 -05:00
Pascal Precht 974803131a uiux: update application and menu icons for macOS
Closes #1278
2021-01-15 10:59:05 -05:00
Michael Bradley, Jr 13daa540e4 build: use a different colored app icon and a non-default STATUS_PORT for dev builds
By default the desktop app uses port 30305, unless a value is specifically set
in environment variable `STATUS_PORT`. For convenience of those developing the
app and running development builds, while simultaneously running production
builds (a.k.a. packaged builds, whether built locally or in CI), have `make
run` invoke `bin/nim_status_client` with `STATUS_PORT=30306`. That value can
still be overriden by manually invoking `make run` with a different value,
e.g. `make STATUS_PORT=30307 run` and `STATUS_PORT=30307 make run` are both
valid and achieve the same effect. NOTE: the port "sticks" in the database
after the first clean run, so when changing ports developers will need to
delete the data dir within their local repository, else the existing database
for dev builds will be stuck using whatever port was used previously. In the
future, we can figure out a means to always update the port setting in the
database just after the login event (but see #1505).

Also, for development builds use an icon (for the running app) that is
orangered (`#ff4500`) instead of the official blue color. This makes it much
easier to select between a running production instance and development instance
when Cmd-Tab'ing (on macOS, or equiv on Linux and Windows) through open
applications. Not all icons displayed at runtime have been changed in this
manner for development builds, just the main application icon, and that seems
to be sufficient to achieve the desired effect; though in the future we could
do similar for notification icon, menu bar icon, etc.
2020-12-18 15:37:06 -05:00
Michael Bradley, Jr ce7e6b8d51 chore: refactor Linux and macOS build/packaging steps
Replaces PR #105.

Implement a `pkg-macos` target that ultimately results in `Status.dmg` being
written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in
`/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into
`bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible
with macOS 10.13 (the oldest macOS version compatible with Qt v5.14).

`pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on
information in a very helpful [StackOverflow answer][so-answer]. Note the part
of the answer (toward the end) that explains a problem with the working
directory and how to fix it. That's the reason for the `nim_status_client.sh`
script introduced in this commit (it gets copied into the bundle). It's also
the reason for having `Info.plist` copied into the bundle before `macdeployqt`
is run (see below) and then overwriting it with `Info.runner.plist` before
creating the `.dmg` file. The app icons file `status-icon.icns` was taken from
`deployment/macos/` in the [status-react][sr] repo.

The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt
into the bundle; it automatically updates `rpath`, etc. so the
`nim_status_client` executable in the bundle can locate the libs within the
bundle.

`macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles,
because of an apparent bug in `macdeployqt` that results in QtWebEngine related
resources not being processed correctly on the first pass. This results in some
bloat in the final bundle but it seems unavoidable at present.

The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg`
file. There are two reasons for this:
1. It produces a nice looking icon for the `.dmg` that overlays the Status logo
on an external disk icon.
2. `Info.plist` needs to be overwritten after running `macdeployqt` (see
explanation above) but before creating the `.dmg` file. If we passed the `-dmg`
cli option to `macdeployqt` to have it generate the `.dmg` file then it
wouldn't be possible to overwrite `Info.plist`.

So there is a cosmetic reason and a practical reason for using another
tool. Probably the biggest downside is that `create-dmg` is implemented in
Node.js so it needs to be installed with `npm`; that's the reason this commit
introduces `package.json`, etc. Note that zero code from `node_modules` ends up
in the `.app` bundle or the `.dmg` file.

Code signing of the macOS `.app` bundle and `.dmg` is attempted if the
environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the
environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the
path to a preferred keychain database file.

Refactor a number of sections in the Makefile for consistency's sake, e.g. the
`appimage` target becomes `pkg-linux` and ultimately results in
`NimStatusClient-x86_64.AppImage` being written to `pkg/`.

Make a number of changes to bring the Linux packaging steps up-to-date and use
the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt
plugins.

Note that `make pkg` will correctly resolve to `make pkg-linux` or `make
pkg-macos` depending on the OS in use.

Consistently use lower-case "c" in the name of *components* directories and
imports.

[limits]: https://developer.apple.com/forums/thread/124782
[brew]: https://brew.sh/
[so-answer]: https://stackoverflow.com/a/3251285
[sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos
[macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html
[cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-22 10:53:57 -05:00