This is required for Notarization, which will be mandatory in macOS
Catalina.
Also, suppress some STL deprecation warnings in PublicUtility code. (The
warnings were recently added to Clang.)
The code for GPMDP is a lot more complicated than the code for other
music players. See BGMGooglePlayMusicDesktopPlayer.h for details.
Adds a class, BGMAppWatcher, to hold the code that notifies listeners
when a given app is launched or terminated.
Resolves#161.
Packages built with package.sh should now be byte-identical except for
timestamps in Assets.car (in BGMApp resources) and modification dates in
the package's Bom file, if built with the same version of Xcode.
Hopefully this will be enough to allow builds to be reproduced, with a
bit of effort.
I don't know why I put them in the Preferences menu initially. This is
more convenient.
Closes#170.
Also:
- Update the output device menu items as needed instead of when the
user opens the menu. This saves a bit of CPU time and means if the
user has the menu open, changes are made when they're needed instead
of the next time the user opens the menu.
- Fix BGMAppUITests::testCycleOutputDevices for the latest Xcode/macOS.
Tries to copy the way CoreAudio normally handles devices being added or
removed, which it can't do while Background Music is running (because
BGMDevice needs to be the default output device for the system).
This may break when Background Music is run on later versions of macOS
as the only way BGMApp can tell what CoreAudio (probably) would have
done is by reading one of its Plist files directly.
See #167.
The most recent tag is now used to decide whether to add "-SNAPSHOT-..."
to the version string. So now we can make a new release by tagging a
commit even if we've already made a snapshot/debug release from the same
commit.
This is required to build against the macOS 10.14 SDK because 10.14
requires users to grant apps permission before they can use audio input
devices or send Apple Events to other apps.
I think builds built against the 10.13 SDK were supposed to continue
working, but I haven't tested it.
Note that without NSMicrophoneUsageDescription and
NSAppleEventsUsageDescription, 10.14 builds will fail more or less
silently when they try to use those features. (tccd does log a message
about it, though.)
See #163.
If HEAD is tagged, check for "SNAPSHOT" or "DEBUG" in the tag name when
generating the version string for a build. If found, add
"-SNAPSHOT-abcdef0" or "-DEBUG-abcdef0" at the end of the version
string (where "abcdef0" is the short commit ID for HEAD).
System sounds are UI-related sounds like mail notifications or terminal
bells.
Xcode 9.2 doesn't support saving .xib files in Xcode 7 format any more,
so building Background Music now requires Xcode 8 or above.
Also, fix some of the tooltips that would only work if BGMApp was the
foreground app, which it shouldn't be.
This is mostly so BGMApp won't leave BGMDevice as the default if BGMApp
crashes, which would stop audio from playing until the user changed the
default device themselves. Also handles SIGINT, SIGTERM and SIGQUIT.
For crashes where the BGMApp process may be in an unknown state, e.g.
segfaults, BGMXPCHelper handles changing the default device.
Should fix the Travis Xcode 9 build, which is currently failing because
the AppleScript we use to quit BGMApp in .travis.yml gets "user
cancelled" for some reason.
Also makes some minor improvements to the reports generated by
CrashReporter. The way CrashReporter works with Background Music should
otherwise be unchanged.
There's still some code left that should be moved into the new class,
BGMBackgroundMusicDevice, but I think this is most of it.
This also helps reduce/contain the code that has to be aware of the
second instance of BGMDevice, which handles UI-related audio.
On macOS, apps are supposed to play UI-related sounds using the "system
default" device. This commit creates a new instance of BGM_Driver, which
BGMApp sets as the system default device. BGMApp ignores audio played to
that device when deciding whether to pause/unpause the user's music
player.
Since UI sounds are short, this helps avoid pausing the music player and
unpausing it shortly after.
The non-interactive version can be called by a Homebrew Cask formula.
Also, change some AppleScript to reference applications by their IDs
rather than their names, which should make them slightly more robust.
BGMApp now disables BGMDevice's volume and/or mute controls if the
output device selected in BGMApp doesn't have matching controls. This
prevents the controls from being presented to the user when they don't
do anything.
In BGMPlayThrough, wait much longer for our IOProcs to stop themselves
before assuming something's gone wrong. In testing, rapidly changing
between output devices with and without controls while playing audio
would occasionally cause one of the IOProcs to take too long to stop
itself.
Also adds some basic scriptability, mainly so UI tests can use
AppleScript to check BGMApp's state that would be complicated to check
otherwise. (In this case, to check which output device is selected.)
Fixes#101.
The UI tests run with clean user defaults, but BGMDevice and Scripting Bridge
still need to be mocked/stubbed out. That also means that the UI tests can only
run if BGMDriver is installed and that changes to BGMDriver's state made during
the tests will persist.
BGM_Device::StartIO blocks on
BGMAudioDeviceManager::waitForOutputDeviceToStart, which could be blocked by
HAL requests that the HAL wouldn't return until BGM_Device::StartIO returned.
Also:
- Replace BGMPlayThrough's move constructor with a SetDevices function for
simplicity.
- Pause/abort debug builds if an error is logged.
Also, default to only aborting debug builds when they log and swallow an
exception if the exception was unexpected. That is, the developer didn't
realise the code could throw.
This reverts commit a4160d370d.
I've tested the icon bug on a couple of other machines now and haven't been
able to reproduce it. My "fix" did cause the bug on those machines, though,
despite fixing it on mine. Still not sure exactly what's going on, but it seems
to be a problem with my development environment.
In BGMApp, messages logged with the DebugMsg macro now go to syslog
instead of stdout.
People running standalone BGMApp debug builds (i.e. not in Xcode) should
be able the find the debug logs more easily. Xcode still shows the debug
logs normally when running BGMApp in Xcode.
Also, debug symbols (the .dSYM directory) are now included in the
Background Music.app bundle. (In both debug and release builds.)
CrashReporter is able to find these and use them to symbolicate BGMApp
crash logs.
The names of the data source(s) for a device are generally the names
intended to be shown to the user, since the OS X volume menu, System
Preferences, etc. use them.
A menu item is now added for each data source of each output device,
rather than one per device.
Also adds some macros/functions for casting values to __nonnull.
Resolves#59.
And other reliability improvements. Mostly in BGMPlayThrough and the
classes that use it. Trying to catch C++ exceptions as early as possible
in the Objective-C++ code and, if necessary, convert them to NSErrors.
More errors are logged in release builds now, which will hopefully help
with debugging issues the developers can't reproduce themselves.
Link to the project website (GitHub) in the About Background Music
window, and move its code into its own class.
Also, update the copyright notices in the UI and README.
- Destroy the Scripting Bridge application object for a music player
when that music player isn't running.
- Move the UI code for the auto-pause menu item into its own class.
- Add a User Defaults class to BGMApp.
- Enable some more warnings for the BGMApp project.
