Is it possible to ask an OSX application which applescript commands it responds to, and if so, how?
You need to look at the Dictionary for an application to see all of the classes and commands the application supports. To get to an application's Dictionary in the the Applescript Editor go to File > Open Dictionary.... A list of all the applications that the OS knows supports Applescript will appear, but the OS won't catch them all so you can use the Browse button. If an application doesn't support Applescript, then it won't be selectable in the dialog window.
The caveat to this is that there are certain commands that an application is supposed to support but don't, or an application may only support the minimum requirements. These are all very, very simple like open, quit, etc. Your mileage may vary.
Related
I have asked another question on AskDifferent about Preveiw scripting dictionaries, and have done a subsequent search here which says Preview is not scriptable.
However when I run:
tell application "Preview"
set save_location to ¬
(choose file with prompt "Choose the png to be modified")
activate
open save_location
end tell
It works. Does that mean that Preview.app is scriptable with Applescript 2.2.1 and Max OS X 10.7.5 which is what I am using?
If so then where can I find a listing of the objects?
All Mac applications respond to the Open and Activate commands even if they do not have dictionaries. Your script works because it exploits the built-in capabilities of any application. The absence of a dictionary means that you cannot query or manipulate open documents and windows (i.e. the application's data model).
However, you can use UI Scripting to select menu items, click buttons within windows, and send keystrokes to the application.
You can find out what Preview's dictionary is by launching /Applications/Utilities/AppleScript Editor and choosing File>Open Dictionary from the menu bar, finding Preview in the list of applications shown there, and clicking Choose.
I want to open another separate application, open the projects/documents of that application in a iterative way and then close the application. I also want to close all the modal and non modals dialogs which popped up during the opening of the document. I want to close all the dialogs including the crash dialog in case the application fails/ crashes.
What will be the best way using cocoa or applescript to achieve this and from where i can get more detailed information?
If the app has a scripting interface, of course the best way is to do that.
You generally don't want to iterate in AppleScript, but rather to operate on all of the results of a query.
For example, for almost any application that implements the "standard suite", you can just:
tell app "TextEdit" to close windows
This is much simpler (and faster, and more likely to be implemented correctly in the target app) than:
tell app "TextEdit"
repeat with theWindow in windows
close theWindow
end repeat
end tell
Of course this may pop up save/abandon changes dialogs, and it may skip over or include dialogs and inspectors, and so on, depending on the application's user model.
More importantly, it won't work if the app doesn't support scripting (and the standard suite).
Also, it won't help at all with closing a crash report—that window is owned by CrashReporter, not the original application (which is a good thing, because you can't talk to the original application anymore, now that it's crashed…).
The alternative is the UI Scripting features in System Events. This will only work if assistive access is enabled. It can also be a bit fiddly to figure out which windows are the ones you want to deal with, and which controls are the ones you want.
For example:
tell app "System Events"
click button 1 of windows of application process "TextEdit"
end tell
This works by finding every window (no matter what kind) owned by the TextEdit process, and simulating a click on the first button in that window (the red close button).
If you google "AppleScript UI Scripting" you should find lots of different guides. The first hit I found was http://www.makeuseof.com/tag/applescripts-ui-scripting-mac/ and it looks like a decent place to start.
I am writing a program to sit in the background on osx 10.6, listen to keystrokes and record them, grouping them by window title. (No, I am not writing malicious software. I do not need this program to be sneaky in any way, I just want to have a safety net for when I have typed a huge email and then accidentally refresh the page (APPLE-R) instead of opening a new tab (APPLE-T)) I have already found apple's EventMonitorTest example for the keystroke capturing code, now I just need to find the "key window" title.
Does anyone know where I can find examples for this kind of functionality? Thank you!
A couple of possibilities:
You could use the Accessibility API (though of course keep in mind that 64-bit Carbon does not support this)
You could use the CGWindow functions introduced in Leopard
I suspect the first option will be easier to do this with, since the CGWindow API is somewhat low-level and treats all windows (application windows, menu bars, dock icons, etc.) more or less equally.
Is it possible to embed Finder functionality in a cocoa app, now that Finder is itself cocoa (assuming the app were to function only in snow leopard)?
What I mean is to have a file browser pane as part of the app, actually browsing the file system itself (to edit in another pane), but without writing all the functionality of the Finder. Thanks!
The Finder itself is just an application. It is not a components library nor a framework. While you cannot "embed" Finder functionality in your application, you can influence Finder functionality and invoke Finder functionality.
First off, you can attach Folder Actions to folders. These will trigger when a user does something to the contents of a folder - for instance, they drop a file into it. You set this up in the Finder. You should to learn a little AppleScript, if interacting with the Finder is something you want to do.
Second, since the Finder supports AppleEvents, you can affect the Finder using AppleScript. Take a look at My First AppleScript and My First AppleScript Part II to see how to do this. Here is much more in-depth information, in AppleScript Overview: Scripting with AppleScript. Here is some More Finder Scripting.
Third, there is also support for developing ways for the Finder to do complex things for the user at the click of a button, using Automator (Mac OS X 10.5). You can also create a Service in Automator, beginning in Mac OS X 10.6 ("Snow Leopard"). Take a look at Automator and Finder Actions in Mac OS X 10.6 for an introduction to this latter technique.
Even though Finder windows themselves are not an embeddable component, if you really want to provide the ability to pen, Print, Delete, Duplicate, etc. Files/Folders, and navigate from Folder to Folder, you can develop a simple Folder browser in your application.
It should not be a huge amount of work to do this so long as you do not set your sites on mimicking the finder or duplicating all of its functionality, just the essential basics I have mentioned.
You would need to know how to program the Macintosh, however - not just use AppleScript. The normal way to do this would be to learn the Objective-C programming language and the Cocoa framework. You would need to get familiar with writing applications using a Model-View-Controller architecture.
You would create a subclass of NSObject named something like MyFile, and a subclass of a collection class named something like MyFolder. When the application creates the browsing Windows, and each time the application activates (becomes the frontmost application), you8 would refresh the contents of the browsing menu.
You could put a menu in your menu bar with commands in it: Open, Print, Delete, Duplicate. When the user does one of those commands, your application performs the appropriate actions itself or sends the request to the Finder. After the action has been completely carried out, then you refresh the browsing window for currently displayed Folder, or newly displayed Folder if the user navigated to a different Folder.
If you are familiar with design patterns, object-oriented programming, and frameworks in general - reading up on Cocoa Design Patterns will speed your learning curve immensely.
These are various techniques you can use to harness some of the power of the Finder. As you look these over, I suggest getting very clear in your mind just what benefit this brings to the user of your application. Writing down what the overall objective of this feature is, and what commands you wish to support, will make it easier to choose the path you take in developing it.
The user can always click on a Finder folder window at the click of a button, since Finder is always running. So avoid simply duplicating that functionality for its own sake. Focus on the benefit you are providing the user. Make sure that you do handle the situations where the user updates the Folder you are showing the contents of from another application and then switches back to your application.
No, they have not made Finder simply a host for a framework, like Preview. You still have to write this yourself.
Using the Apple OS X Cocoa framework, how can I post a sheet (slide-down modal dialog) on the window of another process?
Edit: Clarified a bit:
My application is a Finder extension to do Subversion version control (http://scplugin.tigris.org/). Part of my application is a plug-in (a Contextual Menu Item for Finder); the bulk of my application, however, is in a separate daemon proces. For several reasons, we've chosen to put virtually all the code into the daemon; the plug-in only defines the menu itself, and Apple-Events over to the Daemon.
Sometimes, the daemon needs to prompt the user for further information. It can toss a window on-screen for this, but that's disruptive (randomly positioned), and it seems to me the work flow here is legitimately modal, for example "select a file, pick 'commit' from the menu, provide commit comments, do the operation."
Interprocess cooperation (such as passing a reference of some kind) is acceptable: both processes are mine, but I want to avoid binding the sheet's code into the primary process.
Really, it sounds like you're trying to have your inter-process communication happen at the view level, which isn't really how Cocoa generally works. Things will be much easier if you separate your layers a bit more than that.
Why don't you want to put the sheet code into the other process? It's view code, and view code is inherently process-specific. The right thing to do here is probably to add somewhat generic modal-sheet support to your plugin code, and an IPC call that your daemon can make to summon that code. Trying to ship view objects over to the remote process is going to be nightmarish if you can make it work at all.
You're fighting the frameworks with this approach.
You can't add a sheet to a window in another process, because you have at most only the most restricted access to the windows in the other process.
Please don't do this. Make the interaction nonmodal if at all possible. Especially in something like a commit, it's much nicer to be able to browse around your files while you're writing commit comments.
OS X does have window groups, but I don't think they can (easily) span applications.
Another thing to consider is that in OS X it's possible to have many Finder windows open on the same folder (unlike in OS 9). Even if you did have sufficient privileges/APIs to add a sheet to a Finder window, it's not like the modality of that window would prevent the user from being able to continue working with the files.
(My personal opinion as a long-time Mac user is that this kind of interaction would drive me right up the wall.)