I'm creating a simple OS X FinderSync that adds a menu item to the control/right-click menu for all files:
[FIFinderSyncController defaultController].directoryURLs = [NSSet setWithObject:[NSURL fileURLWithPath:#"/"]];
It's working great (the menu item appears, etc.) for all files, except those in /Volumes Oddly, if I manually create a directory in /Volumes and add some files there, the FinderSync's menu item appears when I right-click. However for any files in any mounted Volumes (i.e. from a mounted .dmg), it fails: no menu item appears.
Directly specifying a mounted volume in the directoryURLs similarly fails:
[FIFinderSyncController defaultController].directoryURLs = [NSSet setWithObject:[NSURL fileURLWithPath:#"/Volumes/SomeMountedDMG"]];
It seems others have had similar issues, so maybe this is a known bug/limitation?
The set of subfolders of a folder monitored by a Finder Sync extension does not cross file system boundaries. Although this is not explicitly mentioned in Apple’s documentation, it can be verified empirically (and is still true as of macOS 10.13.3).
As the intended use case for these extensions is to monitor when the Finder displays specific folders being maintained by synchronization utilities like Dropbox, presumably Apple does not see this behavior as a limitation. However, many developers implement Finder Sync extensions as a way of adding arbitrary items to the top-level contextual menu in the Finder (without being constrained to appear in the Services submenu), even though this usage is explicitly discouraged by Apple:
Make sure the Finder Sync extension point is appropriate for the
functionality you plan to provide. The best Finder Sync extensions
support apps that sync the contents of a local folder with a remote
data source. Finder Sync is not intended as a general tool for
modifying the Finder’s user interface.
To work around this limitation and make the extension’s menu item available for any item visible in the Finder, it is necessary to do the following:
Scan for all visible mounted volumes, and initialize the
directoryURLs property of the FIFinderSyncController object to
the result:
import FinderSync
let finderSync = FIFinderSyncController.default()
if let mountedVolumes = FileManager.default.mountedVolumeURLs(includingResourceValuesForKeys: nil,
options: .skipHiddenVolumes) {
finderSync.directoryURLs = Set<URL>(mountedVolumes)
}
Since Finder Sync extensions are long-lived processes, register
for notifications of volumes being mounted, unmounted, and renamed,
and update directoryURLs accordingly:
let notificationCenter = NSWorkspace.shared.notificationCenter
notificationCenter.addObserver(forName: NSWorkspace.didMountNotification, object: nil, queue: .main) {
(notification) in
if let volumeURL = notification.userInfo?[NSWorkspace.volumeURLUserInfoKey] as? URL {
finderSync.directoryURLs.insert(volumeURL)
}
}
(Handling unmount and rename notifications are left as an exercise
for the reader.)
Related
I'm currently trying to set up a notification service using the old NSUserNotification API on macOSX (not iOS) in objective c++.
The catch is that I would need to know the system preferences associated with notifications that the user set (and preferably during the rest of runtime too) to determine if my notifications are actually seen. The application is meant to get the users attention in some way to guarantee things like reminders don't go unnoticed, so the thing I want to avoid is a notification delivered that silently doesn't produce any sound nor image on the screen whatsoever without the application knowing. If the notification is not allowed the application should handle it in some other way.
I am working on a macOS 10.14 Mojave machine. My overall code with NSUserNotificationCenter works fine with a custom Delegate that implements shouldDeliver, didActivate etc. Its just that I am currently assuming the user didn't press the "frick off" button on my notifications.
Unfortunately, NSUserNotificationCenter and related classes don't appear to feature a function that determines the permissions the way the new API (UNUserNotificationCenter) does. I have been trying to resolve this for a few hours so I was wondering if anyone else has found a solution to this. I can't really use the new API since this is strictly for back-compatibility in favour of the possibly rather prevalent amount of people who don't use mojave yet.
Things I have tried to make it work so far:
Try and see if there is a .plist somewhere where these settings are stored, in the User-specific Library folder as well as the general Library folder.
Try and find said .plist using CFPreferencesCopyKeyList and related methods. Apparently I don't really know the right domain name.
This answer from 2012 which appears to be outdated since I cannot locate the database on my machine anymore. Might be due to me using a mojave machine, or the file has since moved somewhere else.
Try and determine whether we can retro-actively check our permissions by checking a NSUserNotification's "presented" property on didDeliverNotification, shouldPresentNotification in the delegate. Unfortunately as stated in NSUserNotificationCenter itself it still behaves the same whether the preferences allow notifications or not.
Some code I tried includes the following:
CFPreferencesCopyKeyList((CFStringRef) #"com.apple.systemPreferences.plist", kCFPreferencesCurrentUser, kCFPreferencesCurrentHost);
CFPreferencesCopyKeyList((CFStringRef) #"com.apple.systemPreferences.plist", kCFPreferencesAnyUser, kCFPreferencesAnyHost);
//Unfortunately returns null with any combination of com.apple.notificationcenter.plist, kCFPreferencesCurrentUser, kCFPreferencesCurrentHost
CFPreferencesCopyKeyList((CFStringRef) #"com.apple.notificationcenter", kCFPreferencesAnyUser, kCFPreferencesAnyHost);
On my system (only macOS High Sierra), it looks like the file you're after is:
~/Library/Preferences/com.apple.ncprefs.plist
That would correspond to a combination of kCFPreferencesCurrentUser, and kCFPreferencesAnyHost. (For the record, kCFPreferencesCurrentUser + kCFPreferencesCurrentHost equates to pref files in the ~/Library/Preferences/ByHost/ folder).
I don't think any settings would be stored in the local domain (by that I mean in the root /Library/Preferences/ folder).
I was able to get a list of apps and settings using the following code:
[[NSUserDefaults standardUserDefaults] addSuiteNamed:#"com.apple.ncprefs"];
NSArray *apps = [[NSUserDefaults standardUserDefaults] objectForKey:#"apps"];
NSLog(#"[%# %#] apps == %#", NSStringFromClass([self class]), NSStringFromSelector(_cmd), apps);
NOTE: this will not work if your app is sanboxed, as access to other pref files like that will be denied.
Basically I want make sure I execute a custom written .applescript every time Safari is opened.
I tried adding the script to the "~/Library/Scripts/Applications/Safari" folder but that doesn't seem to automatically do it.
As a workaround I can probably just write an AppleScript that both starts Safari and runs my custom stuff. I just wanted to check whether there's a cleaner way of doing this.
Putting stuff in the ~/LibraryScripts/Applications folder just makes them available when the particular application is active.
In addition to your alias that runs the script and Safari, you could use some AppleScriptObj-C in a background application (maybe run via login items) that registers for NSWorkspaceDidLaunchApplicationNotification notifications to get the names of applications as they are launched. This would also have the advantage of seeing when Safari gets launched other than from your alias, such as via various document links (Mail, PDFs, etc):
use framework "Foundation"
my addObserver:me selector:"appLaunchNotification:" |name|:(current application's NSWorkspaceDidLaunchApplicationNotification) object:(missing value)
on appLaunchNotification:notification -- an application was launched
# notification's userInfo contains the application that was launched
set applicationInfo to NSWorkspaceApplicationKey of notification's userInfo -- NSRunningApplication
set appName to (localizedName of applicationInfo) as text
-- do your thing depending on appName
end appLaunchNotification:
From time to time, but not always (I have had this working for a bit), the app/extension gets in a state where I can't read a flag set in my App Group between my companion app and my app extension. Don't know how it gets in this state or why the values differ, but it's critical to my application these always be in sync.
Companion app viewDidLoad:
NSUserDefaults *myAppSettings = [[NSUserDefaults alloc] initWithSuiteName:#"group.myapp"];
.....
[myAppSettings setBool:true forKey:#"myBool"];
[myAppSettings synchronize];
NSLog([myAppSettings boolForKey:#"myBool"] ? #"Companion app - bool TRUE" : #"Companion app - bool FALSE");
App extension viewDidLoad
NSUserDefaults *myAppSettings = [[NSUserDefaults alloc] initWithSuiteName:#"group.myapp"];
[myAppSettings synchronize];
NSLog([myAppSettings boolForKey:#"myBool"] ? #"App extension app - bool TRUE" : #"App extension - bool FALSE");
Console output
Companion app - bool TRUE
App extension - bool FALSE
I also synchronize before my companion app will enter background. I have my app group set up in the portal etc.
What am I doing wrong?
EDIT
Apparently others having this problem too:
https://devforums.apple.com/message/977151#977151
"I think that this is currently very glitchy.
Sometimes the data sharing works, then a change and all of a sudden the widget can't see the shared data anymore (both on Simulator and device).
Annoying and hope it's a bit more reliable in next beta!"
EDIT 2
Looks like another person has reported this exact issue as well:
"I also noticed the same thing too.This not only happen to the
NSUserDefaults, but also all the files in the container folder. The
keyboard extension suddenly will lose read/write pemission to the
container folder after using the keyboard for a while."
EDIT 3
More evidence: https://devforums.apple.com/message/1028078#1028078
After I upgrade to beta 3, I noticed that sometimes the keyboard
failed to open the database because it failed to access to the DB
file. The keyboard has been able to access to the file before.
EDIT 4
Seems like this could be because the keyboard loses the RequestsOpenAccess flag. But I can't reproduce it, and there's no way for me to tell for sure.
EDIT 5
Seems like others are reporting this in the iOS8 GM build:
This issue still persists for me in the GM. It seems related to a
keyboard crash.. but also there seems to be some contention between
keyboard and containing app in terms of who creates the suite in what
order. I think this problem is on Apple's end. Trust me, I WANT it to
be my fault but I've spent countless hours with trial and error. No
matter what I do in code and verify with NSLog, it will end up in this
state eventually. Hoping someone finds a magic pill. :S
Has anyone solved this yet?
You must request open access in order to access shared NSUserDefaults. It's stated directly in the App Extension Programming guide:
By default, a keyboard has no network access and cannot share a container with its containing app. To enable these things, set the value of the RequestsOpenAccess Boolean key in the Info.plist file to YES.
Be sure you change the RequestsOpenAccess field to YES. You'll find it in keyboard's Info.plist > NSExtension > NSExtensionAttributes > RequestOpenAccess. Then remove the keyboard in Settings, delete the app, run it again, and add the keyboard again. After you add it, tap on the keyboard name and then flip the switch to enable Allow Full Access. You'll need to instruct the users to follow those same steps to grant access (and reassure them you're not evil), otherwise it simply will not work and you'll never get the data that's stored in your shared container. Note that in iOS 8.3+, if the user hasn't enabled full access the keyboard will be able to access the shared container, but writing to it will not save the data, for security and privacy purposes. In 8.2- you can't access that data without open access granted.
I can confirm that the problem is related to RequestsOpenAccess flag.
Assuming that everything done right (NSUserDefaults use initWithSuiteName, all Capabilities for main application and custom keyboard were set, etc.) I have the next steps:
1) Install the main application and a custom keyboard on device
2) Set 'Allow full access' for the custom keyboard to YES
3) Add some items (in my case this is a simple text templates) in the main app
4) Go to keyboard and check that all items, that were added from the main app,
appeared in custom keyboard
5) Go to main app and add a few more items
6) Go to keyboard and now you will see that nothing changed
7) Go to settings and switch 'Allow full access' to NO and then to YES
8) Go to custom keyboard again and check that item which were added in step 5 appeared.
I would like to create a system tool / application which has the capacity to aid in window management. I'm trying to find documentation about the following topics, if they are indeed possible given the security sandboxing of OSX.
Show a list of running applications with the name & icon, and allow the user to choose one
Manipulate the frame(s) of said application's windows (eg, resize, reposition) from my app (with animations -- though I assume this will be trivial once I can perform the actual change)
Hide or show these applications from task managers, etc.
Be able to launch (or terminate) instances of the given application
It seems to me that Quicksilver accomplishes many of these things, but the lack of AppStore availability makes me wonder if it possible to do this while remaining in the OSX sandbox.
There are a lot of pieces of software out there that do window management. You can check out a tiling window manager I've been hacking on called Amethyst. The basic idea behind software like this relies on Accessibility (which you can find documentation for here). As a quick overview the APIs work by acquiring references to accessibility elements (applications, windows, buttons, text fields, etc.) which have properties (hidden, position, size, etc.), some of which are writable.
As an example let's say that you wanted to move all windows in every running application to the upper left corner of the screen. That code might look like
for (NSRunningApplication *runningApplication in [[NSWorkspace sharedWorkspace] runningApplications]) {
AXUIElementRef applicationRef = AXUIElementCreateApplication([runningApplication processIdentifier]);
CFArrayRef applicationWindows;
AXUIElementCopyAttributeValues(applicationRef, kAXWindowsAttribute, 0, 100, &applicationWindows);
if (!applicationWindows) continue;
for (CFIndex i = 0; i < CFArrayGetCount(applicationWindows); ++i) {
AXUIElementRef windowRef = CFArrayGetValueAtIndex(applicationWindows, i);
CGPoint upperLeft = { .x = 0, .y = 0 };
AXValueRef positionRef = AXValueCreate(kAXValueCGPointType, &upperLeft);
AXUIElementSetAttributeValue(windowRef, kAXPositionAttribute, positionRef);
}
}
Which illustrates how you get references to applications and their windows, how to copy attributes from an accessibility element, and how to set attributes of an accessibility element.
There are a variety of notifications documented in NSWorkspace for the launching and termination of applications, and the accessibility framework also has a sense of notifications for things like an application creating or destroying windows, or a window miniaturizing or deminiaturizing.
Animating the window changes is non-trivial and I haven't figured out how to do it yet, though it may be possible. It may not be possible at all without hitting private APIs. But the other things you have listed should be possible. Hiding an application, for example, could be done by setting the kAXHiddenAttribute on the application accessibility element. Launching an application can actually be done via -[NSWorkspace launchApplication:].
Note that the use of accessibility necessitates that the user have Enable access for assistive devices turned on in System Preferences > Accessibility.
My question is quite simple :
To use a custom menu for the apps icon on the dock, - (NSMenu*) applicationDockMenu: (id) sender; of the NSApplicationDelegate has to return the menu that the dock will display.
Using setImage on a NSMenuItem, you can normaly add icons to the menu. They show up on the normal menu, but not on in contextual menu of the app's dock icon.
Then how did Apple manage QuickTime, XCode, Preview to show icons in the list of recent opened files accessible in their dock contextual menu ?
Thx.
The recent files list is actually part of the standard Dock icon menu. To use it in your app, you should build an NSDocument-based application. By using NSDocument, you will get the recent files menu/behaviour for free.
If your application cannot be based on NSDocument, you can instruct Cocoa to maintain a recent documents list based on URLs:
NSDocumentController *docController = [NSDocumentController sharedDocumentController];
[docController noteNewRecentDocumentURL:locationOfMyRecentFile1];
[docController noteNewRecentDocumentURL:locationOfMyRecentFile2];
[docController noteNewRecentDocumentURL:locationOfMyRecentFile3];
Note that currently, -noteNewRecentDocumentURL: only supports file:// URLs (which you can create from a path with +[NSURL fileURLWithPath:].) In the future, its behaviour will presumably change to allow URLs with other schemes.
Here's my understanding, which is partly conjectural and related to implementation details:
The Dock runs in a separate process, and you can't pass an arbitrary NSImage trivially across the process boundary from your application to the Dock. There are only two kinds of images that can be passed properly: standard system icons, and icons in your resource bundle. But I don't think NSImage does the necessary incantations for either of these to work.
So you're going to have to use Carbon. Specifically, you need to use SetMenuItemIconHandle with either kMenuSystemIconSelectorType (covers Carbon IconRefs, obtained with GetIconRef) or kMenuIconResourceType (CFStrings that refer to an .icns file in your application bundle's Resources folder).
The relevant headers are <HIToolbox/MacApplication.h> (for GetApplicationDockTileMenu), <HIToolbox/Menus.h> (for SetMenuItemIconHandle) and <HIServices/Icons.h>, (for GetIconRef, if you're using system icons).
Untested, but it should look something like this:
#include <Carbon/Carbon.h>
SetMenuItemIconHandle(
GetApplicationDockTileMenu(),
[dockMenu indexOfItem:dockMenuItem],
kMenuIconResourceType,
(Handle) CFSTR("icon.icns")
);
It may not be this simple; some of this may be 32-bit only.