Best Practices for GUI Scripting

AppleScript
#1

Hey there Script Debugger community!

I am new to scripting and trying to navigate these waters by collecting as much wisdom as I can early on. I am new to scripting itself, as well as to Script Debugger itself so be patient with my newbie questions, please!

I am looking for some recommended Best Practices for AppleScript, but GUI Scripting in particular. I have learned that sometimes GUI scripting is the best/only way to get something done, but it’s so powerful! However, it also has its own workflow and approach, I have noticed, too.

Ok on to the questions:

  1. How do you guys organize/ archive/ access and run your scripts? Do you just place them in the Scripts folder and run them using the menu bar or is Keyboard Maestro the recommended method (this seems to be) or something else? I imaging you guys have lots of scripts and I was wondering how you manage them.

  2. I have successfully accomplished my first GUI script! However, I have noticed that it is very “hard coded”, meaning it is specific to the exact document I am on (with the exact title). How do I adjust my GUI scripts to me more reusable? Script example below of what i am talking about.

  3. I have noticed that the scripts run too fast sometimes. Is there a recommended way to pace the scripts so they execute consistently and generate errors?

  4. What questions should I be asking as a newbie that I am not here?

Sorry for the long post. Any feedback on any of these questions is appreciated. Ray had recommended getting UI Browser and WOW, WHAT A TOOL! UI Browser and Script Debugger are a powerful combo. Now just looking to add in the wisdom of the community.

Thanks so much!

My first GUI Script:

tell application "Keynote"
	activate
end tell

tell application "System Events"
	tell its UI element "Keynote"
		tell its window "Untitled"
			tell its toolbar 1
				tell its radio group 1
					tell radio button "Format"
						click
					end tell
				end tell
			end tell
		end tell
	end tell
	
end tell
2 Likes
#2

I usually save them as applications and call them with Spotlight. To get fast SL searches I use special characters in the name that are unlikely to appear in “normal” strings. Like “>Debugger” for “Open in Script Debugger”.

adding a “delay [nb of secs]” usualy does it, like “delay 0.1”

#3

You should be able to replace that line with

tell its front window

or sometimes

tell its front document

or

tell its current tab

All depends on what app you’re working in.

#4

What Phil said on this. I often reference windows by index—window 1—though as far as I know front window should work the same, unless there is something quirky going on. A few applications scripted directly don’t identify the frontmost window as window 1.

Delay is often the last resort, and works. But if you need it to work under all circumstances, see if you can check to see if a window or dialog exists. If not, then delay, and repeat until the item shows up. That’s especially useful if you need your scripts to work on other Macs where things may happen slower or faster.

Congrats on your first GUI script!

Ray

#5

bodiequirk,

GUI scripting can do things that nothing else can. But they are often hard to work with. Timing is often a big issue with GUI scripting. Sometimes you end up with delay statements scattered through a script. Nothing is ever documented. GUI scripting often uses undocumented objects, the objects are often harder to figure out than the command. GUI interfacing may not match the scripting interface and some GUI can be very slow. A single command might not be so bad, but GUI scripting in a repeating loop can be very slow.

I would think working with more conventional scripting in the beginning might be easier. Practicing reading scripting dictionaries form different applications and writing progressively more complicated script can teach some very useful skills. Documentation on doing this kind of stuff is far easier to find.

I wouldn’t call GUI scripting a powerful method because it is so low level that making any kind of sophisticated script would be very tedious, filled with trial and error and would take a while. But working with something that has poor, or no, scripting it is often the only way.

Apple Pages, Numbers, Keynote, BBEdit, Text Wrangler, Apple Mail, Safari, Script Debugger, Script Editor, and Preview are reasonable easy to work with and there is lots of sample code that can be found for them. UI Browser is a great program but sometime it is insanely slow so you have to be patient with it.

I’ve known a number of people who use Keyboard Maestro and like it. I use FastScript and like it but there are a number of such utilities out there that can be used.

I have been scripting for a long, long time and nearly all the things that turned out the best were the AppleScripts I wrote that leveraged the power of Applications to produce powerful results. When I do use GUI scripting I do as little as possible with GUI scripting and the rest I do with AppleScript.

I hope this helps. Good luck.

Bill

#6

Bill,

Thanks for the thorough replay to my request. Much appreciate your time and wisdom in this post. I am definitely going to do my best to keep to pure AppleScript when I can.

The only reason I even discovered GUI scripting (I am sure that I would have found out about it eventually anyway) was from my initial post here about wanting to script Keynote and not finding the elements that I wanted to target in the Keynote dictionary. Then I discovered there was another, more secret, way! (Lord of the Rings reference, anybody?)

I have really appreciated UI Browser so far for speeding up my ability to find the object I need. From there, I have just been using that as a map to use to navigate Script Debugger’s System Events explorer. I don’t like how UI browser writes the code, so I let Script Debugger do that, but it sure saves time because it gives you the names of all the objects instead of having to constantly guess and expand/collapse Script Debugger’s infinite System Events explorer window.

Along with all of this I am reading AppleScript 1-2-3 and really trying to get the fundamentals correct. Sal’s iWork Automation website has taught me a ton, as well, about what AppleScript can do, and should look like.

So much to learn! At least now I feel like I can get to whatever I want, and then learn the best way to code it as to optimize the native advantage of the AppleScript language and benefit from GUI scripting when necessary.

Glad to have found Script Debugger and this community. So excited to learn and grow from all of your wisdom and experience.

#7

Ray,

thanks again for these tips. This is the kind of “fundamentals” stuff I don’t think of. Want to get good at “AppleSript thinking” like this. Checking for the right criteria first before executing actions can save lots of frustration I imagine!

Thanks again!

B

#8

A comparison to Cirith Ungol might be the best, most succinct description of GUI scripting I’ve read. You only go that way when there are no other options and time is pressing!

Ray

1 Like
#9

bodiequirk,

When it comes to any good AppleScript book they are all out of print. But all of them can be purchased on line in electronic form which means they are searchable and available for purchase.

I would have also mentioned “AppleScript 123” in this list but you already have that one. Just click the book title below and it will take you right to the web page were they are sold.

Learn AppleScript:The Comprehensive Guide to Scripting and Automation on Mac OS X (2010)
by Sanderson, H., Rosenthal, H., Piper, I., Wainwright, B., Levy, E., Monihart, H., Williams, C., Stanley, S.

AppleScript: Developer Reference (2010)
By Mark Conway Munro

“AppleScript 123” came out in 2009. It is a good book that is written in an easy to read format. “Learn AppleScript” is also an easy to read book. These are the 2 books I use as reference to look up AppleScript stuff in.

What sets these 3 books apart from other good books on AppleScript is they are the most recent good books on AppleScript. Some AppleScript books were great books in their time, but are just to out of date now to be of much help now.

All 3 of these books come in a pdf format that is fully searchable from Apple Preview and Adobe’s pdf reader. When new to AppleScript being able to search a book electronically is very helpful. Also all 3 of these have sample code that can be downloaded. This is true even if you have an old paper version of AppleScript 123.

When someone is new to AppleScript sources of learning that have sample code are usually the best. Not only can you see how to do something, but you see different ways to do the same thing and that can really help later on when you start writing lots of scripts.

Bill

#10

I think Sal’s MacOSXAutomation.com site is one of the best to learn AppleScript from.

There is also the MacScripter.net tutorials. I was going to provide a link to these, but I can’t seem to find them now. There are a number of these on basics like “Dates”, “Lists”, etc that are really helpful. Maybe @ShaneStanley can point us to them.

EDIT: 2017-04-17 8:08 PM CT
Here are the tutorials:

After that I don’t have a preferred book, although I own and have read several.

Now days I find that I can most quickly learn something new by a Google search.

Finally, I have learned that AppleScript is missing so many of the basic, core functions that I am use to in other languages (like strings, dates, arrays, records/objects, RegEx) that I initially found AppleScript very frustrating. You can write your own handlers for a lot of this, but some you can’t, unless you want to use ASObjC.

What I have found is that there are several tools that I prefer to use rather than reinvent the wheel:

#11

Jim and bodiequirk,

macscripter is one of those sites that doesn’t use a .com domain. The URL is:
http://www.macscripter.net

Bill

#12

Bill, I’m well aware of that. In my post is used the correct .net domain.

#13

Jim,

Sorry about that. I reread you message and I have no idea how I got to thinking you didn’t know the URL. The neck and back injury that disabled me sometime make it very hard to focus and it being a real pain today.

Bill

#14

This is one of the real valued-added extra bonuses of SD6. I’ve never had to use Spotlight or Finder to find my scripts since I started using it. Use the ‘Open Quickly’ function( Command-Shift-O), type in any term you can remember from the script and it’ll return all the scripts you have that contain that term. Like Spotlight, only i. quicker and ii. dedicated to search script files and bundles.

1 Like
#15

Cool! But that’s when you want to work in SD, right? Not when you want to actually launch stuff?

#16

Chris Stone (@ccstone) created a text tag system of using the “@” symbol and keyword as the tag. For example, “@SD”. The “@” symbol helps differentiate the keyword from other text.

You can enter this text tag as part of the script file name and/or in the script file contents. Since Spotlight gives more weight to the file name than to file contents, I have started naming all of my script files using the @keyword approach.

This works extremely well with:

  • Spotlight search
  • Finder Search
  • SD6 Open Quickly Search

For example, I include “@UI” in the file name of all scripts that deal with UI scripting.

1 Like
#17

I load and run scripts from SD, or they’re in FastScripts Script menu, so I don’t have to go finding them.

#18

I see. I don’t consider Spotlight as a “finder”, rather like a “launcher”. Trying to stick to “out of the box” solutions… Using metadata works nicely too.

#19

Yeah, I can see the utility in that. Chris is a super-organised person (you can tell from his scripts). Me, I’m a bit more chaotic. If we were haircuts, Chris would be a short-back-and-sides and I’d be a clump of dreadlocks. I love systems like this in theory, but the reality of my nature is I just don’t stick to them. It’s why Open Quickly is a godsend for me. It does all the work I need it to, and lets me carry on being the messy, disorganised, dishevelled kind of guy I am (it’s why scripting and automation are a godsend to me, too!).

1 Like
#20

Oh, me too - well certainly up to Mavericks - but since Yosemite and all this Spotlight Suggestions crap (as much of which as possible I’ve got turned off) that was introduced, it’s not nearly so fast or responsive as it used to be for quick app launches.

A few years ago I had a big debate with someone on a forum about whether Spotlight or LaunchPad was the fastest way to launch an app. It was a pretty conclusive win for Spotlight.

However, since Yosemite the jury is out as far as I’m concerned. I went from a ‘never use that crap Launchpad’ person to a ‘lets give Show Launchpad a hotkey’ person, and now I can usually launch an app faster with the LP hotkey while Spotlight is still rubbing its hands together and deciding what it wants to show me first.

The other issue with Spotlight that seems to have become worse is when you have several externals attached with backup or alternate copies of the app (clones can be a nightmare) ending up with you launching the wrong version or wrong install of an app. You don’t get any of that with Launchpad. You don’t get any “think” time with it either.

So, ctl-opt-cmd-space and sd and return gets me this launched either as quick or (especially near login or boot times) faster than cmd-space and sd and return with Spotlight.

Screen Shot 2017-04-18 at 20.56.19.png1104×618 86.3 KB