AppleScript
Blog

Safari Kiosk Tabs

02/02/09 09:03 Filed in: Watershed

An AppleScript to ensure that new Safari windows are opened in a tab

In the Watershed Café/Bar there are a number of ‘Slacker Tables’—public web browser kiosks set in glass tables. Oliver asked about a way to ensure that the instances of Safari running on the tables would open a new tab and not a new window. This is a simple AppleScript, to be saved as an Application and run, in a loop in the background.

This was only a quick, five minute hack but the results are surprisingly usable. Running the script as an application in the background doesn't appear to affect performance or stability over longer periods of time.

Note: this script has only been tested with Safari 3.2.1 in MacOS X 10.5.5

  1. repeat
  2. delay 1
  3. tell application "Safari"
  4. if the (count of documents) > 1 then
  5. set theURL to the URL of the front document
  6. if theURL is not "" then
  7. close front document
  8. tell front window
  9. -- Safari appears to only let the front window create tabs
  10. set theTab to make new tab
  11. set current tab to theTab
  12. set the URL of theTab to theURL
  13. end tell
  14. end if
  15. end if
  16. end tell
  17. end repeat

Tags: , ,

|

Scriptable Applications

11/07/06 18:19 Filed in: Watershed

AppleScript is thought of as an 'added extra' for desktop applications but for internal tools it should be an essential on the 1.0 feature list.

Many shrink-wrapped, commercial applications do not add AppleScript support until later versions and with internal tools developed in-house it is an even lower priority. Many of these internal tools have a quick and dirty UI and none, or little, online help so being scriptable is not very likely.

With Cocoa applications adding AppleScript support is relatively easy and quick to implement. This is certainly the case in applications that are strongly based around a business logic model with data objects, as many internal tools are, and are already Key Value Coding compliant. Cocoa AppleScript support will do lots of the work for you.

So why should an in-house developer make their applications scriptable?

AppleScript support will free up developer time. If I write a scriptable application, the staff members who use the app or Oliver, Alex or Paddy of our ICT department can add new features or work around bugs without waiting for me to deploy the next version. I can spend my time implementing features that really need to be done rather than a feature to 'duplicate every cinema screening in Cinema One on every second Wednesday in the month'.

Watershed will gain from increased productivity from a scripted workflow. We could save so much time with a script that created the web data from the brochure:

  1. tell application "Quark XPress"
  2. repeat with every text box in the front document
  3. tell application "Communicate"
  4. set newExhibit to make new Exhibit
  5. set the title of newExhibit to the first line of text box
  6. save newExhibit
  7. end tell
  8. end repeat
  9. end tell

AppleScript support is a springboard or stepping stone to an Automator Action that even more users can make use of with even less training. Actions can be built by the users or by our ICT department.

If I ever left the Watershed, being able to implement some new features using AppleScript would give the users and ICT a breathing gap before a new developer could be employed and was up to speed with the application.

There are many other reasons to make any application scriptable that are often just applied to commercial development. These are just some reasons to add AppleScript support to internal tools.

Tags: ,

|

odds&ends…
Benjamin Miller