AppleScript User-Interaction Helper Functions

[smarg19]

I have recently gotten frustrated with the complexity required to generate nimble user interactions in AppleScript. By nimble, I simply mean able to function elegantly in all environments. For example, I only recently figured out that the surest way to have a dialog box appear and be active is to use something like this:

try
	tell application (path to frontmost application as text)
		display dialog "Hello world!"
	end tell
on error errText number errNum
	if not (errNum is equal to -128) then
		tell application id "sevs"
			display dialog "Hello world!"
		end tell
	end if
end try

Such a script will ensure that the dialog box appears front-and-center, but that's overly verbose for my tastes. 

So, to start to solve this problem, I began working on some Helper Functions to simplify the major user interaction functions in AppleScript. So far, I have:

• display_dialog
• choose_from_list
• choose_file
• choose_folder
• display_notification
• display_alert
• say_text

 

Each of these functions accepts a record with all of the dialog information (all its parameters) and will construct the script then run it within the above framework. Currently I use "z_" prefixes for most of the keys. So, the fullest possible record to pass to the display_dialog function would look like:

set r to {z_text:"This is the dialog text", z_answer:"My Default Answer", z_hidden:false, z_buttons:{"Yep", "Nope"}, z_ok:"Yep", z_cancel:"Nope", z_title:"Title", z_icon:"/Users/smargheim/Downloads/dropbox_pdf.png", z_wait:5}

There is documentation within each of the functions, and I hope to have better documentation later (this was an afternoon project). While I've just begun this project, I think it could prove useful to the q_workflow framework. To display a dialog, therefore, all you would need (if you put the as_helpers.scpt file in your workflow folder), is something like this:

--Load the script with the Helper Functions
set _help_ to load script POSIX file (POSIX path of ((path to me as text) & "::") & "as_helpers.scpt")

set r to {z_text:"This is the dialog text", z_answer:"My Default Answer", z_hidden:false, z_buttons:{"Yep", "Nope"}, z_ok:"Yep", z_cancel:"Nope", z_title:"Title", z_icon:"/Users/smargheim/Downloads/dropbox_pdf.png", z_wait:5}
_help_'s display_dialog(r)

I haven't forked the q_workflow files yet, but you can view my helper functions, along with samples, at the GitHub page:https://github.com/s...eScript_Helpers

If others think that this might prove beneficial, I think I'll fork my own version of q_workflow that includes these functions.

stephen

[smarg19]

For anyone, like me, who may want to use these functions through Python, here is my base code. I use the `alp` module for interacting with Alfred and Dr. Drang's `applescript` module for piping Applescript from Python (see here: http://www.leancrew.com/all-this/2013/03/combining-python-and-applescript/). In my workflow's root folder, I have the functions script named "_user-interactions.scpt". Here's the code for creating a dialog box with the workflow icon:

from dependencies import applescript
import alp

# Load user-interaction helper functions, and deploy
a = """
	set _help_ to load script POSIX file (POSIX path of "%s" & "/_user-interactions.scpt")
	
	set r to {z_text:"This is the dialog text", z_buttons:{"Yep", "Nope"}, z_ok:"Yep", z_cancel:"Nope", z_title:"Title", z_icon:"%s/icon.png", z_wait:5}
	_help_'s display_dialog(r)
""" % (alp.local(), alp.local())

print applescript.asrun(a)[0:-1]

As noted above, the keys for the record are fixed, but the values are totally variable. This is a clean, terse way to generate Applescript user interaction dialogs and popups, even thru Python. 

[smarg19]

I recently added a number of bug fixes and improvements to the GitHub code. FWIW

[ipaterson]

I think that some localization support would be nice as well. I don't see many workflows leveraging strings files but also don't really know what the demand is for Alfred workflows that are compatible with different languages.

 

In addition to the UI Element localization problems discussed in the other thread, I think it would be great to automatically localize any strings provided to your helper functions. I use a strict approach requiring that all strings are localized, but the more common and appropriate in this case is to just allow AppleScript to return the original text if a translation is not available. For example:

 

on l10n(text)
    return localized string of text in bundle getWorkflowFolder()
end l10n

 

Then wrap each string you use in that. Workflows can include folders such as en.lproj, es.lproj, etc corresponding to the supported languages with a Localizable.strings file in each mapping the strings from English to the target language.

Edited March 3, 2014 by ipaterson

[deanishe]

I don't see much point in putting in the significant effort to internationalise workflow UIs: Alfred isn't available in any language but English, so by definition an Alfred user kind of has to be fine with English.

 

That said, the output of a workflow should be localised where appropriate, e.g. if a workflow generates dates/numbers, it'd be nice if they could be formatted in a manner appropriate to the system locale, e.g. "1,5" and "15.01.2014" not "1.5" and "15/01/2014" if the system is German, not English. Or indeed "01/15/2014" for Americans.

[smarg19]

I've recently updated with another set of helper functions for using Applescript with Alfred workflows. Most of it is a procedural approach to many of qWorkflow's object-oriented functions. There is also my own simple version of an Applescript JSON parser. It currently only reads non-nested JSON, but this is all I use with settings and preference files. 

 

Find it all here: https://github.com/smargh/AppleScript_Helpers