Five Ways to Request an Application Restart

Sometimes when you modify a preference setting in a software application, a restart is required for the change to take effect.

Such settings used to be accompanied by a line of text, stating that “Changes to this option won’t take effect until you relaunch the application”.

Nowadays, applications are more helpful in reminding you of a required restart, or even take care of that for you.

To give you a few examples for how developers address this process, here is a look at five Mac OS X applications that require a restart when you show or hide their icon in the Dock or menu bar.

Growl: Do what I say (if you know what that is)!

After changing the icon setting in Growl, a dialog box informs you that the application “must restart for this change to take effect”.

Dialog box displayed in front of Growl's preferences window, and stating that a restart is required for a settings change to take effect

When I saw this dialog box for the first time, I expected the application to restart once I would click the OK button. I found that idea irritating, because I thought, “What if I don’t want to restart the app now? Where’s the Cancel button? Why can’t I back out of this?”

And then I did click OK — and wondered whether the program was buggy, because nothing happened.

It took me a while to understand that this dialog box is purely informational. It does not serve as a warning that the app would actually restart as soon as you click OK.

I would find it helpful if the dialog box expressly prompted you to initiate that restart, e.g., by adding something like “Please quit and restart Growl when you’re done adjusting the settings”.

Better yet, provide a Restart button right inside the dialog box.

Mouseposé: Would you like to restart now, or wait a while?

The “Relaunch required” dialog box in Mouseposé does include a Restart button. A button labeled Later lets you defer the relaunch.

Dialog box displayed in front of Mouseposé's preferences window, and stating that a restart is required for a settings change to take effect

If you do click Later, the change you made to the Show Icon radio buttons is retained, even though the corresponding changes have not been applied to the application’s behavior.

For example, when you change the setting from “Dock and Menu Bar” to “Menu Bar”, and click “Later” in the dialog box, the icon is still shown in both locations.

I see two problems in this behavior.

First, you cannot rely on the preferences displaying the application’s actual settings — i.e., how it behaves right now —, nor can you easily go back to the previous settings.

Second, once you’ve deferred the relaunch and worked with the application for a while, you may forget about having changed any settings. If you then relaunch the application, its changed behavior may come as a surprise and confuse you.

Skitch: Lemme take care of that for you

Skitch‘s icon options are similar to Mouseposé’s. Instead of bringing up a dialog box and allowing the user to defer the relaunch, however, Skitch completely automates the process.

https://uiobservatory.com/media/2011/AutoRelaunchSkitch.png” alt=”Skitch preferences window with a note underneath the “show icon in” option, explaining that the application will automatically restart after a settings change if that is required” border=”0″ width=”400″ height=”302″ />

As it says in the info text underneath the radio buttons, Skitch will simply relaunch if the settings change requires it. The user does not have to do anything, except wait for the application to restart.

Tell me where I can find you

The icon options in Skitch and in Mouseposé have something important in common: You cannot hide both Dock and menu bar icons at the same time. The application will always appear in at least one of these two locations.

Other programs support being turned into background-only applications that are completely hidden from the user’s view. Usually the only means to summon these applications is a keyboard shortcut.

TextExpander: Restart now, or else …

TextExpander is one such application that can hide from the user.

When you select the “Hide TextExpander icon in Dock” option, a warning dialog box will not only inform you that a relaunch is required. It also recommends you define a keyboard shortcut and/or activate the software’s menu bar icon so that you can easily access the application after the relaunch.

Dialog sheet explaining that TextExpander needs to be restarted for a settings change to take effect

Unlike the previously mentioned software programs, TextExpander does not allow deferring the restart. If you choose Cancel, TextExpander clears the option’s checkmark you had just set.

A detail that I found mildly irritating about this dialog box is that its text message always stays the same, regardless of whether a keyboard shortcut has been set or whether the menu bar icon is visible.

I wish the application would provide a bit more guidance to the user by reflecting these settings. E.g., if a keyboard shortcut is set, the dialog box could remind the user accordingly: “To open TextExpander, press Command-Alt-Control-T. You can modify this keyboard shortcut in the Hotkeys preferences panel.”

LaunchBar: Treacherous toggle button at work

In LaunchBar, you can only show/hide the Dock icon, because the application does not have a regular menu bar to begin with. Instead of a checkbox for this option, LaunchBar uses a toggle button.

I’ve written about potential problems with “treacherous” toggle buttons before, and the one in LaunchBar has similar issues.

LaunchBar's Advanced preferences panel featuring a button to 'Hide Dock Icon…'

When you click the button “Hide Dock Icon…”, an elaborate message will point out to you what side effects this setting will have.

Dialog sheet in LaunchBar with a long bulleted list outlining the effects that hiding the application's icon from the dock will have

When the button says “Show Dock Icon…” while you click it, this message does not appear. A relaunch reminder appears after every single click on the button.

LaunchBar's dialog sheet to inform the user that a restart of the application is required

The label on the “Hide/Show Dock Icon…” button will change if you defer the restart, so that it can get out of sync with the actual application’s behavior, just like the settings controls in Mouseposé.

What’s more, when you click Later in the relaunch warning dialog and then repeatedly click the “Hide/Show Dock Icon…” button, the bulleted warning list will show up every time you click “Hide …”.

In contrast, the restart warning never appears again until you actually do quit the and then restart LaunchBar.

A personal opinion

Changing the icon settings in Mouseposé and Skitch is risk-free: You will always be able to “find” either application, because they do not allow you to hide both Dock and menu bar icons at the same time. Consequently, there is no need for a warning beyond requesting the relaunch.

In cases such as these, I like Skitch’s approach of simply restarting itself as necessary, as it does not require any decision making from the user. It just takes care of what needs to be taken care of. “Let the machine do the work for you.”

If there is a risk involved in the settings change — like the application becoming “invisible”, etc. — a confirmation dialog is required.

For these, I prefer TextExpander’s approach of forcing the user to make a decision then and there: Accept the settings change and restart the application, or cancel the restart and discard the settings change.

This is the only way to ensure that what’s displayed in the application’s user interface reflects the actual settings in the application’s guts and, consequently, the software’s behavior.