Inside a Finder tell statement, the term folder is indeed a class. You would need to use the statement outside the tell statement, or use something from the Finder itself such as the kind property, for example: set myVariable to (kind of (directory as alias) is "Folder") Note that kind can differ from info for, since bundles/packages such as applications are technically also folders. The privilege violation is from using the info for command (a long deprecated StandardAdditions command) in a Finder tell statement. There are a few that don't trigger the warning, such as display dialog, but common practice is to only use statements inside an application tell statement that specifically target that application. The terms my or of me can be used for statements that target something else (handlers, etc), but this case is problematic in that the result from info for actually uses scripting terms for the record keys.

VIP is an item related to the Mail "Smart Mailbox" or Contacts "Smart List" constructs, in that it is just something that can be used in a search from which the application can do something like show the results in one of its normal views. While the application can use these results internally, it would need to provide a mechanism for a user to access or use them (or not). As mentioned, if a term (such as a VIP property) is not declared an application's scripting dictionary, the app doesn't provide it, and you can't just make it up. Mail places the VIP data in the VIPMailboxes.plist (XML) and VIPs.plist (binary property list) files in the ~/Library/Mail/V10 (or whatever version) /MailData folder, where they can be used by the app along with other search terms. It may be possible to edit these files, although you would need to figure out what they are using for the keys and how they are linked to the messages.

I just threw those out there because I was aware of them. To build the GitHub project you would need Xcode and know a little about how to use it in order to shuffle around some of the build settings (I'm not much of an Xcode or Swift guy either). It looks like you may have downloaded an older version of SKProgressBar, which has been around for a while and is from one of the regulars at MacScripter.net. The latest released (signed and notarized) version of that is at ht tps://klieme.ch/Downloads/SKProgressbar/SKProgressBar2.0.zip (remove the space, I didn't include it earlier as the forum won't accept it as a link).

How the built-in progress indicator is shown is dependent on what is using it. For an Automator workflow or a script from the Script Menu, the progress is shown in a status item menu by the system's ScriptMonitor application. For each process it just has a menu item with a circular progress indicator and descriptive text, but note that for an Automator workflow the progress is for the workflow itself - e.g. how many actions have been completed. A separate third-party background (agent) application such as SKProgressBar or swift-progress could be used, as it would handle its own dialog independent of the script or workflow. This can also avoid issues when updating the progress in a repeat loop, since normally that doesn't give the built-in progress indicator time to update.

AppleScript hasn't changed much since then; the documentation is still the AppleScript Language Guide (even though it hasn't been updated in a while). There is also the Mac Automation Scripting Guide. If you are wanting to interact with applications, AppleScript is still the way to go - check the app's scripting dictionary for whatever terminology it provides. For Notes.app, a note does have an ID property. The checkmarks appear to be a different feature separate from the HTML content of the note. It doesn't look like this functionality is exposed to AppleScript, although you can create new notes using your own HTML source.

The scripting terms are used when compiling a script that targets the application. What are you trying to accomplish?

Automator and AppleScript applications can be passed files like any other app. Is there a particular reason for using one to run the other?

The Get Specified Finder Items action will only return those items, and the Get Selected Finder Items action returns the current selection in the front Finder window. Your workflow isn't getting anything to move, unless there happens to be a current FInder selection. You would need to do something like use Get Folder Contents on the specified folder(s), and then filter those items for folder names. You may also be able to use Find Finder Items to combine the getting and filtering actions. To see what a specific action is returning, you can view its result.

Actions are designed to perform a specific task, which is usually general-purpose in nature. They do what they do. I don't know what you did before to get windows moved, but your posted sample workflow isn't going to work at all. Take a look at the action info, which specifies what the input and output will be. Opening files returns files (not windows), and the window actions require a window (not an image) to resize or move, which isn't specified anywhere. Also note that there isn't a line connecting the actions, which indicates they aren't compatible (there isn't anything to convert the action's input/output). You would need to do something like open the files in Preview, wait a little bit to let them open, then have the Find Windows action filter for Preview windows. From there, you would need to loop through the windows, resizing and moving as desired, but now you are fighting what Shortcuts was designed to be (like a graphical shell script), and might as well use something more designed for the task, like a 3rd party action or scripting. Shortcuts (and Automator) have their purpose, but they aren't really designed for much beyond batch workflows without some help.

Automator and Shortcuts built-in actions are general-purpose in nature, based mostly on existing shell utilities or common functions, or a developer was generous and decided to include some to support their application. There are tiling and window moving scripts out there (various scripting forums, GitHub, etc), but you would need to graft them into your specific workflow (Run AppleScript, Run Shell script, etc). Other options would be to find 3rd-party actions or make your own, although manipulating the UI is a pain no matter what you use.

The usual approach would be to save whatever the existing delimiters are, set the delimiters to what you want to use, split the string into a list of its text items, restore the previous delimiters, and then just use the list. You are continually splitting the string to get each piece, so all it would take is for the delimiters to get changed/reset somewhere else in the bigger script for the text items to be different the next time you split the string. Another option would be to try using the words of the string.

Finder and/or System Events can provide some information (see their scripting dictionaries), and the Cocoa API (via AppleScriptObjC) can use framework methods such as NSURL's getResourceValue. You would need to provide additional details for a more specific answer.

OK, I am getting a few different errors, but the problem seems to be that for whatever reason (looks like a bug), when you initially click in the window or use the divider or history, the window accessibility properties are not getting set up. Clicking the window again gets things set up, but until then the "front" window doesn't have any properties for the script to use, such as selected tab, so trying to use that throws an error. Unfortunately, this also prevents targeting the window by name, id, tty, etc, so I haven't found a workaround other than to click the window a couple of times before running the script. A command line tool to do the clicking could probably be used, but you would need to get information about the "front" window to get the bounds to click into, which would most likely be way more involved than what you are doing now.

If you are talking about the split pane view, your script sample works for me in Sonoma. You mention a handler - is the handler being called differently, such as from another tell statement?

This is one of those situations where learning some basics instead of having others do everything helps. The posted script just has some quoting issues - either escape the double quotes for use in the string, or use single quotes since the shell also understands those. The corrected script would be: set myFile to choose file -- choose a package or or try `choose folder` to select a folder set theCommand to "(test -d " & quoted form of POSIX path of myFile & " && echo 'is a dir') || (set status 0; echo 'not a dir') ; 2>&1" return do shell script theCommand