I'm currently developing a macOS cocoa application. Within one of the windows I'm gathering values from multiple arrays and building an xml file as a key/value backup. After saving the file I'm wanting to set a custom icon for the particular xml file. I've searched throughout stackoverflow and the rest of the web and haven't been able to find any solutions. Throughout the different functions within my application I'm able to pull a previously set icon from a file but haven't been able to set one for a newly created file. Any assistance would be greatly appreciated.
In order to change the XML file icon you should use that:
[[NSWorkspace sharedWorkspace] setIcon:iconImage forFile:path options:0];
Where iconImage is a NSImage of the icon and path is the path of the xml file. Note that the change may not be visible until you rename the file or restart the computer. A workaround is renaming the xml file and then renaming it with the old name back again.
Also, note that macOS icons are different of Windows and Linux icons, so that icon may only be visible in macOS systems (in some cases, only in your machine).
Related
I have a shoebox type (as opposed to document based) OS X app that stores images in the app's sandbox container.
These images can be shared via Share Extensions (in form of a NSURL) or exported via drag and drop.
When an image is shared to an image editor (e.g. Acorn offers a Share Extension), or dropped on an image editor, the image editor opens the file from within my sandbox container and can now alter, rename or delete this file - which can lead to all kinds of inconstancies in my app.
First, I was surprised, because I thought, files in the sandbox can only be accessed by the app itself. But it seems this is not the case, when I intentionally share the NSURL.
So how can I prevent that someone can alter files in my sandbox container while still offering them for drag and drop and to Share Extensions?
I tried not sharing NSURLs but NSImages, but many Share Extensions do not work with NSImages, so this is not a good option.
Is it a possibility to write-protect the files in the sandbox?
Should I always make a copy of an image to a temporary location, before I offer it for sharing or drag and drop (could be slow for big images?)
I am happy to hear your suggestions or learn more about the problem.
Create a bookmark of the NSURL.
So the user can still rename, move and delete the file, but you notice it and know the new location and name and still are able to access the file. Should work even if it's outside your sandbox.
So you can handle this.
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSURL_Class/
That's one of the benefits working with NSURL and not with a simple path string.
In my Mac app I have an NSMetadataQuery to watch the app's iCloud directory. When the user decides to enable iCloud from within the app I do the following in this order:
Call [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil] to establish access to the iCloud container
Start a NSMetadataQuery to find all files (pattern: "*") in the iCloud container
Now I iterate over all files in the local container and move them to iCloud by using [fileManager setUbiquitous:YES itemAtURL:fileURL destinationURL:targetURL error:&error]
I have two types of documents that I move to iCloud:
The actual documents stored as file packages
For each document I have a .preview file as simple binary file
My problem is that the meta data query only returns my binary preview files, but not my actual documents until I relaunch my app (or open a Finder window of the app's iCloud folder from the Terminal - in this case my app gets another query result with all files).
So is this some weird caching issue? Is this because the documents are file packages and not simple binary files?
I don't see why that should be a problem. If I restart my app the query does return all files correctly.
Could this be a problem with the way my custom document type is exported in Info.plist?
Could this be a problem with the way my custom document type is
exported in Info.plist?
I suppose so: the issue you are describing is most likely because your document format is a file package (I assume written with NSFileWrapper). Remember that the package bit is set when writing the file, so if you have other apps writing to iCloud, that could make the issue much more confusing as it's not about interpreting a file bundle but writing it in a correct manner.
NSMetadataQuery unfortunately ignores folders, so your files will never be reported back unless you have correctly registered your filetype as bundle in the application that writes the file to the iCloud container.
There are a lot of similar and potentially confusing settings in the info.plist, so many things that can go wrong. I experienced an issue when I registered my document filetype correctly on OS X, but failed to do so on iOS: https://stackoverflow.com/a/14993694/388412
The first thing you should do is to go to https://developer.icloud.com/#documents and see if you're looking at files (correct) or folders (problem).
Work on your info.plist document types until you see the documents as files, then it should work.
I have a Cocoa app "PDFHistory" on Mac OS X that uses the NSDocument architecture to save and load PDF files that are internally formatted specially for my app. I want to make it so whenever I save a file (e.g., "mydoc.pdf") from PDFHistory, then subsequently double-clicking on mydoc.pdf will automatically open it in PDFHistory.app. However, I don't want to make it so all .pdf files are automatically opened in PDFHistory, but rather use the system default (probably Preview.app). The .pdf suffix is a requirement, though, since I need the user to be able to e-mail the files to other users who can view the file in their default PDF viewer.
The problem is that if I set the LSHandlerRank to "Owner", then all .pdf files will be opened with PDFHistory, which is bad (since I only understand the internals of the .pdf file that PDFHistory wrote out). But if I set LSHandlerRank to "Alternate", then all .pdf files will be opened to the system default app (Preview.app), which is confusing for the user who had just created the file using my app.
Once upon a time, "creator codes" could be used to implement this sort of capability, but launch services started ignoring them back in Snow Leopard (see http://tidbits.com/article/10537). UTIs are not a substitute that provide this capability (see http://boredzo.org/blog/archives/2009-09-22/how-not-to-use-utis).
Using Finder to get info on the file allows the user to specify a specific app to use to open the specific file. This supposedly works by setting a "usro" property in a the file's resource. There is some open-source code to mimic this behavior (https://github.com/AlanQuatermain/SetAppAffinity), but is uses deprecated functions, and so would cause Apple to reject the app from the App Store. Similarly, people have posted AppleScript to set this property (https://discussions.apple.com/thread/2597365), but sandboxing would prevent me from invoking it.
Although the .pdf suffix is a requirement in order to be able to send the files to users on other systems/platforms, I considered trying to have the suffix registered with two extensions as ".phistory.pdf", which would allow "file.phistory.pdf" to be opened in PDFHistory, but "file.pdf" would be opened in the default PDF viewer. However, this simply didn't work: it appears that the final suffix is the only one used by launch services, and everything before that is ignored.
So is there any way to have my app be the default app for opening files that it created itself?
My application uses new proprietary file formats with extensions never been used before. I would like to associate specific icons to display my files in finder with nice iconography. As far as I know LaunchService is responsible to handle all these data, however I'm confused where, when and how shall I create associations.
Which entries I have to add to plist?
Where I need to actually register this extension - during installation? Is there any script for this?
Add a CFBundleDocumentTypes key to your plist, see
Storing Document Types Information in the Application's Property List
I want to be able to run a text editor from my app, as given by the user in the TEXT_EDITOR environment variable. Now, assuming there is nothing in that variable, I want to default to the TextEdit program that ships with OSX. Is it kosher to hardcode /Applications/TextEdit.app/Contents/MacOS/TextEdit into my app, or is there a better way to call the program?
Edit: For the record, I am limited to running a specific application path, in C. I'm not opening a path to a text file.
Edit 2: Seriously people, I'm not opening a file here. I'm asking about an application path for a reason.
In your second edit it makes it sound like you just want to get the path to TextEdit, this can be done easily by using NSWorkspace method absolutePathForAppBundleWithIdentifier:
NSString *path = [[NSWorkspace sharedWorkspace] absolutePathForAppBundleWithIdentifier:#"com.apple.TextEdit"];
Mac OS X has a mechanism called "uniform type identifiers" that it uses to track associations between data types and applications that can handle them. The subsystem that manages this is Launch Services. You can do one of two things:
If you have a file with a reasonably well-known path extension, e.g. .txt, you can just ask NSWorkspace to open the file in the appropriate application.
If you don't have a well-known path extension, but you know the type of data, you can ask Launch Services to look up the default application for that type, and then ask NSWorkspace to open the file in that specific application.
If you do it this way you'll get the same behavior as the Finder, and you won't have to fork()/exec() or use system() just to open a file.
I believe hardcoding "Applications" will not work if the user's language setting is not English. For example in Norsk the "Applications" folder is named "Programmer".
The Apple document on internationalization is here. Starting on page 45 is a section on handling localized path names.
I believe that Mac OS X provides a default application mechanism, so that .txt will open in TextEdit.app or Emacs or GVim or whatever the user has specified. I couldn't find anything online however.
You could run following command from your application:
open <full path to text file>
This will open the text file in the default text editor. You can open any file type using open command.