PolytreeDE/alacritty
1
0
Fork 0
mirror of https://github.com/alacritty/alacritty.git synced 2024-11-25 14:05:41 -05:00
Code Releases Activity
alacritty/extra/osx/Alacritty.app/Contents/Info.plist

59 lines
2.4 KiB
Text
Raw Normal View History

Add Makefile and .app
2017-01-12 05:01:52 -05:00
<?xml version="1.0" encoding="UTF-8"?>
On macOS when launching multiple times focus win (#941) I dug into this and narrowed the issue down to the macOS app bundle Info.plist file. So, I spun up a native macOS app real quick and tested it by launching the binary directly and launching it via the app bundle. When launching from the command line directly, it created multiple windows & instances of the app. However, when launching via the app bundle it behaved as I normally expect a macOS app to behave, that is when launched multiple times to simply focus the already existing window and instance. This informed me that it wasn't something in code as much as it was something in the app bundle configuration. Hence, I reworked the Info.plist file based on the one that was created by XCode when I made the native macOS app and it started behaving as expected.
2017-12-13 16:30:27 -05:00
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
Add Makefile and .app
2017-01-12 05:01:52 -05:00
<plist version="1.0">
<dict>
On macOS when launching multiple times focus win (#941) I dug into this and narrowed the issue down to the macOS app bundle Info.plist file. So, I spun up a native macOS app real quick and tested it by launching the binary directly and launching it via the app bundle. When launching from the command line directly, it created multiple windows & instances of the app. However, when launching via the app bundle it behaved as I normally expect a macOS app to behave, that is when launched multiple times to simply focus the already existing window and instance. This informed me that it wasn't something in code as much as it was something in the app bundle configuration. Hence, I reworked the Info.plist file based on the one that was created by XCode when I made the native macOS app and it started behaving as expected.
2017-12-13 16:30:27 -05:00
<key>CFBundleDevelopmentRegion</key>
<string>en</string>
<key>CFBundleExecutable</key>
<string>alacritty</string>
<key>CFBundleIdentifier</key>
<string>io.alacritty</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>Alacritty</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleShortVersionString</key>
Bump version to 0.9.0
2021-08-03 05:46:27 -04:00
<string>0.9.0</string>
On macOS when launching multiple times focus win (#941) I dug into this and narrowed the issue down to the macOS app bundle Info.plist file. So, I spun up a native macOS app real quick and tested it by launching the binary directly and launching it via the app bundle. When launching from the command line directly, it created multiple windows & instances of the app. However, when launching via the app bundle it behaved as I normally expect a macOS app to behave, that is when launched multiple times to simply focus the already existing window and instance. This informed me that it wasn't something in code as much as it was something in the app bundle configuration. Hence, I reworked the Info.plist file based on the one that was created by XCode when I made the native macOS app and it started behaving as expected.
2017-12-13 16:30:27 -05:00
<key>CFBundleSupportedPlatforms</key>
<array>
<string>MacOSX</string>
</array>
<key>CFBundleVersion</key>
<string>1</string>
<key>CFBundleIconFile</key>
<string>alacritty.icns</string>
<key>NSHighResolutionCapable</key>
<true/>
<key>NSMainNibFile</key>
<string></string>
<key>NSSupportsAutomaticGraphicsSwitching</key>
Reenable macOS automatic graphics switching This issue has been resolved upstream by a macOS update, fixing all crashing issues when switching between integrated and dedicated GPUs. Fixes #2221.
2019-05-14 11:36:13 -04:00
<true/>
On macOS when launching multiple times focus win (#941) I dug into this and narrowed the issue down to the macOS app bundle Info.plist file. So, I spun up a native macOS app real quick and tested it by launching the binary directly and launching it via the app bundle. When launching from the command line directly, it created multiple windows & instances of the app. However, when launching via the app bundle it behaved as I normally expect a macOS app to behave, that is when launched multiple times to simply focus the already existing window and instance. This informed me that it wasn't something in code as much as it was something in the app bundle configuration. Hence, I reworked the Info.plist file based on the one that was created by XCode when I made the native macOS app and it started behaving as expected.
2017-12-13 16:30:27 -05:00
<key>CFBundleDisplayName</key>
<string>Alacritty</string>
Opt-in to macOS Mojave Dark Mode macOS 10.14 will bring a new system wide dark mode. To enable this, the [official guides][] suggest to relink using the newest OS. This approach, however, did not work for me as described in [an issue][] in the glutin repository. As a second option, the accompanying `Info.plist` file can also overwrite the link-time check and enable dark mode rendering if the system config is set by setting `NSRequiresAquaSystemAppearance` to `YES`. This approach seems to work flawlessly no matter if a user opts into dark mode or not. I would appreciate it if someone can test this on macOS 10.13 as well, but I suppose the key there is unused and would not break anything. [official guides]: https://developer.apple.com/documentation/appkit/appkit_release_notes_for_macos_10.14_beta [an issue]: https://github.com/tomaka/glutin/issues/1053#issuecomment-409315461
2018-09-18 16:27:40 -04:00
<key>NSRequiresAquaSystemAppearance</key>
<string>NO</string>
Request OSX privacy permissions
2018-12-02 11:06:24 -05:00
<key>NSAppleEventsUsageDescription</key>
<string>An application in Alacritty would like to access AppleScript.</string>
<key>NSCalendarsUsageDescription</key>
<string>An application in Alacritty would like to access calendar data.</string>
<key>NSCameraUsageDescription</key>
<string>An application in Alacritty would like to access the camera.</string>
<key>NSContactsUsageDescription</key>
<string>An application in Alacritty wants to access your contacts.</string>
<key>NSLocationAlwaysUsageDescription</key>
<string>An application in Alacritty would like to access your location information, even in the background.</string>
<key>NSLocationUsageDescription</key>
<string>An application in Alacritty would like to access your location information.</string>
<key>NSLocationWhenInUseUsageDescription</key>
<string>An application in Alacritty would like to access your location information while active.</string>
<key>NSMicrophoneUsageDescription</key>
<string>An application in Alacritty would like to access your microphone.</string>
<key>NSRemindersUsageDescription</key>
<string>An application in Alacritty would like to access your reminders.</string>
Add NSSystemAdministrationUsageDescription to macOS manifest This resolves permission failures when modifying root-owned files and such, e.g., modifying /etc/hosts. It had been possible to work around this by adding alacritty to the set of applications with "Full Disk Access" in System Preferences. macOS now opens a prompt to confirm permission with a new installation. This fixes #2337.
2019-05-07 11:49:22 -04:00
<key>NSSystemAdministrationUsageDescription</key>
<string>An application in Alacritty requires elevated permissions.</string>
Add Makefile and .app
2017-01-12 05:01:52 -05:00
</dict>
</plist>
Copy permalink