Archive

Archive for the ‘Automator’ Category

Showing and hiding all desktop icons via the command line

June 26, 2016 3 comments

As part of preparing for a presentation, it’s often handy to be able to hide the icons on your desktop so that folks viewing the presentation aren’t distracted by what you have stored on your desktop.

To aid with this, there are defaults commands which can be run to hide or (if hidden) show the icons on your desktop.

To hide your desktop’s icons, run the command shown below:

defaults write com.apple.finder CreateDesktop -bool false

To show your desktop’s icons, run the command shown below:

defaults write com.apple.finder CreateDesktop -bool true

After running the appropriate command to either show or hide the desktop’s icons, the Finder needs to be restarted so that it can display the changes. You can do this one of two ways:

1. Log out, then log back in
2. Run the following command:

killall Finder

Since I usually remember only at the last minute that I should hide my desktop icons, I’ve also built an Automator application named Show or Hide Desktop Icons.app to assist me with showing or hiding my own desktop’s icons. For more details, see below the jump.

Read more…

Apple Setup Assistant and First Boot Package Install Generator.app

June 22, 2016 2 comments

A while back, I built an Automator application named First Boot Package Install Generator.app. It’s designed to generate installer packages, where the generated packages in turn serve as a delivery mechanism to enable other installer packages to be installed when a Mac boots up.

As part of the process of installing the other installer packages, an application named LoginLog is supposed to open over the login window and display a log of what actions are taking place, what is being installed and whether that particular installation succeeded or not.

Screen shot 2014 10 19 at 2 39 21 pm

For the most part, this process of launching LoginLog and displaying the log works as designed but it was brought to my attention that there was one scenario where LoginLog did not appear as expected. When a firstboot package created by First Boot Package Install Generator.app was installed onto a new installation of OS X El Capitan, LoginLog did not appear over the Setup Assistant.

Screen Shot 2016 06 21 at 8 11 00 PM

The reason it didn’t appear is because the LaunchAgent for LoginLog is triggered by the Mac being at the login window.

Screen Shot 2016 06 21 at 8 04 30 PM

However, Apple’s Setup Assistant on El Capitan no longer runs over in the context of the login window. Instead, it runs in the context of an account named Setup User.

Screen Shot 2016 06 21 at 8 07 23 PM

In order to have LoginLog appear again in this scenario, I needed to develop a method which could accomplish two tasks:

  1. Suppress Apple’s Setup Assistant during the time when I wanted the LoginLog application to appear.
  2. Avoid interfering with an otherwise desired launch of the Apple Setup Assistant.

For more details, see below the jump.

Read more…

Setting Microsoft Outlook as the default application for email, contacts and calendars via Automator

December 1, 2015 8 comments

While working on an Outlook 2016-related issue earlier this week, I found that there is not a straightforward way to set Microsoft Outlook 2016 as the default application for email, contacts and calendars. To redress this, I’ve developed an Automator application named Set Microsoft Outlook as default application for email calendars and contacts.app to handle this task.

The Set Microsoft Outlook as default application for email calendars and contacts application leverages duti, an open source tool used for managing application ownership of document types and URL schemes on Mac OS X, to set the newest version of Microsoft Outlook on the Mac as the default application for email, contacts and calendars.

The application includes an embedded copy of duti, so it is not necessary to have duti pre-installed on the Mac in order to use this tool. For more details, see below the jump.

Read more…

Automator’s Ask for Finder Items windows no longer showing text prompts in OS X El Capitan

November 30, 2015 2 comments

As part of working with Automator to build applications, I’ve been leveraging the ability of Automator’s Ask for Finder Items action to set text prompts in my Automator-based applications.

These text prompts are included in the appropriate Finder windows and have been an easy way for me to set a particular message in an Automator selection window.

Screen Shot 2015 11 30 at 9 43 34 AM

I recently noticed in OS X El Capitan that these messages no longer appear, which is a bit inconvenient as it leaves users of my applications with no clear direction as to what to do when this window appears.

Ask for Finder Items windows in OS X El Capitan and OS X Yosemite 001

 

It does not appear that AppleScript is affected by this issue, as the comparable AppleScript function properly displayed the desired text in both Yosemite and El Capitan.

Screen Shot 2015 11 30 at 10 16 47 AM

As a workaround to keep my applications’ users informed on what to do, I’ve set standalone AppleScript notifications to appear in my Automator applications before the Ask for Finder Items Automator action’s window.

Screen Shot 2015 11 30 at 10 03 56 AM

All three of my Automator-based applications have now been updated with the workaround:

 

I’ve filed a bug report with Apple on this issue. For those interested in duplicating this, it is bug ID 23688457. I’ve also cross-posted the bug report to Open Radar, so the bug report details are available from the link below:

https://openradar.appspot.com/23688457

Recovering Automator workflows from Automator applications

August 1, 2015 1 comment

Every so often, source code for an application gets lost, mislaid or not given to a customer. In that case, the application’s user may need to do a lot of work to decompile the application and see if the source code can be recovered from the application itself.

I recently had a colleague ask about a similar situation with an Automator application, where they had the Automator application itself but didn’t have access to the Automator workflow that created it.

After some testing, here’s how we were able to access the workflow using only the compiled application.

1. Save a copy of the Automator application to a convenient location.

Screen Shot 2015 08 01 at 8 16 21 AM

2. Right-click on the application and select Show Package Contents.

Screen Shot 2015 08 01 at 8 16 47 AM

3. Save a copy of Contents/document.wflow to a convenient location.

Screen Shot 2015 08 01 at 8 17 00 AM

4. Rename document.wflow to preferred_file_name_here.workflow.

5. When prompted, confirm that you want to change the extension from .wkflow to .workflow.

Screen Shot 2015 08 01 at 8 17 28 AM

At this point, you should be able to open the newly-renamed .workflow document in Automator and examine the workflow.

Screen Shot 2015 08 01 at 8 17 42 AM

 

Screen Shot 2015 08 01 at 8 17 56 AM

Update 8-1-2015: Steve Hayman pointed out that there’s an even easier way. For details, see below the jump.

Read more…

Categories: Automator, Mac OS X

Customizing Automator application icons

July 19, 2015 Leave a comment

As part of my work with packaging, I’ve built a few Automator-based applications to assist me and other Mac admins.

Along with building the applications themselves, I wanted to provide custom icons for these apps. This would help them be instantly distinguishable from other Automator applications and also help make them look more polished.

I recently decided to change out the application icon for Payload-Free Package Creator, as its icon had been created on Mavericks and now appeared a little dated when used on Yosemite. With input from my colleague Elliot Jordan, the new icon for Payload-Free Package Creator now looks like this.

Payload Free Package Creator logo

For more information on how I went from this PNG file to an icon set for the application, please see below the jump.

Read more…

Categories: Automator, Mac OS X

Payload-Free Package Creator.app Revisited

May 21, 2015 6 comments

I do a lot of work with payload-free packages and while I have a process for creating them as I needed them with pkgbuild, this approach requires some setup work. To help make the package creation process more convenient, I developed Payload-Free Package Creator.app, an Automator application that will allow to select an existing script and create a payload-free package that runs the selected script.

However, this tool has used pkgbuild‘s –nopayload function, which creates a package which doesn’t leave an installer receipt behind. This is intended behavior according to Apple, but not leaving a receipt behind can make it hard to determine whether an installer package has been run on a particular machine. This is especially problematic for Munki, which uses receipts along with other methods to track installation status.

While I don’t use Munki, I’ve heard from a number of folks who do and who had run into the no-receipt problem when they tried to use payload-free packages generated by Payload-Free Package Creator.app with Munki.

So the problem was this:

  1. I wanted to create payload-free packages which only run scripts and do not install files.
  2. I wanted to have an installer receipt.
  3. Apple’s built-in method for generating payload-free packages with pkgbuild didn’t provide receipts.
  4. I thought I needed to provide a payload to pkgbuild in order to generate a package which would provide receipts.
  5. Providing a payload meant I was installing files, which is what I didn’t want to do.

The matter had rested there for a while and I didn’t see a good way to fix it.

Fortunately, I was wrong about point 4. Greg Neagle recently documented that you can make a package with pkgbuild that, while not technically payload-free, will act just like one. The key is to create an empty directory and set pkgbuild‘s –root option to look there for files. pkgbuild‘s –root option is used to tell pkgbuild which files to package, but since there will be no files in an empty directory, the package will install no files on the destination Mac.

That’s where I had gone wrong on point 4 – I thought I had to give pkgbuild something to install in order to build a package with a receipt, but it turns out that pkgbuild will successfully build a package while using an empty payload directory. This information allowed me to reconcile points 1 and 2, which resolved the problem.

With this new information, I was able to update Payload-Free Package Creator.app and I’m happy to announce it has two new features:

  • Version numbering
  • Packages generated by Payload-Free Package Creator.app will leave receipts behind after installation.

For more details, see below the jump.

Read more…

%d bloggers like this: