| AppleScript (osascript) dialogs are at the same time both pretty simple and wildly complex. I’ll try to cover most of the big gotchas, but also try to avoid letting this become a dissertation. I’ll provide script text below, just be careful of line breaks and auto-correct.
Basic construct is to have AppleScript “tell” an application to display a dialog. Prior to Sierra this meant calling “System Events”, but Sierra’s management of the TCC database makes that a little more complicated. The code block listed below should work on Sierra and several previous versions of the OS
The “display dialog” option can really have three formats, one to display a pop up of pure text with buttons, one to display a text entry field, and one to allow the selection from a list (multi-select is an option here). You can also customize the message displayed, the title bar, the buttons (up to three, I believe), and the icon displayed. For icons, there are three built in options, a stop sign, a warning triangle, and a note page; or you can supply an implicit path to any icon file (such as a corporate logo).
I tend to build several of my commonly used combinations into a pre-made function, that I can then call as needed. The simplest I use of these is:
====
displayDialog(){ echo "$1" /usr/bin/osascript <<EOT tell application (path to frontmost application as text) display dialog "$1" buttons {"Quit","OK"} default button 2 cancel button 1 with title “Mac IT" with icon note end tell EOT if [[ "$?" = "1" ]]; then echo "User opted to exit." exit 1 fi }
====
Now the hard part, the hardening. I’ll get back to the second half of that function in a moment, but for now, I need to talk about some other behaviors of osascript dialogs. First off, after about 5 minutes, the dialog will exit; if you’ve specified a default button, that button behavior will occur upon that timeout, otherwise the osascript command itself will just exit with error code 1 (like it was missing an argument). This means that you have to plan for the user walking away, and how your script is going to handle if the osascript dissolves, or sends the default result. In your case, as Erik mentions, I would absolutely default to not setting the user’s homepage.
In my specific usage (essentially asking the user if they want to proceed with the installation), I supply a quit button. The “cancel” button (you can specify the button text, as I do above, so that it reads “Quit”) will return text to stderr, and then the osascript command will exit with error code 1. Which is the point of the second bit in the function above. I’m checking the exit status of the osascript, and if it exited with error code 1, I’m then passing that exit code to the entire function. I then have a similar block in the main script that checks the exit code of the function, and if sees an error state, exits the script with that error state.
For your use case, I would suspect you want 2 buttons, one that leaves the homepage alone (the default), and another that sets the homepage. You could either have the script look for the output of those buttons, or you could have the leave alone button just exit the script (if setting the homepage is the only thing the script does, this is likely the easier route).
I hope this at least gets you pointed in the right direction. If you have further questions, don’t hesitate to reach out.
Conor
P.S. I don’t want to derail the conversation with a soapbox, but I will echo Erik’s comments here, do you really need to set the homepage? Would a webloc profile (which puts a link to the site in the dock) be a viable alternative? Or deploying a webloc file to their desktop? Or any of several other options that might be less invasive to the user than stomping on their homepage choice?
On Nov 3, 2016, at 1:41 AM, Eugene Kondrashev < email@hidden> wrote:
Hi Conor,
Thank you for you response, it definitely helps. I'll look into second option, will appreciate any reference/example on the post-install script example
Thanks, Eugene
|