Comment 7 for bug 1346355

Let me first draw attention to the edit I made to my initial Bug Description: I have expanded the Bug scope to the fact that the popup-dialog repeats itself AND the power-cog icon does not turn red. After a system updates, only one restart-popup should present (it serves informational purposes while offering the user with an immediate way to reboot, should they want to). If the user declines this popup, then the power-cog should turn red and no further popups asking for restart should present at any time.

Matthew, many of the examples you use do not bolster the case for a repeating popup-dialog. When a battery is getting moderately low, the battery status icon goes red. This is as it should be. When the battery is critically low (and your computer is going to turn itself off or change its runlevel state), you get a dialog. This is as it should be. When you update your system and a restart is needed (but your computer is not going to change its runlevel state if you fail to interact with the dialog) the dialog is purely informational and offering a choice. If the user declines to reboot, the appropriate response is to give a red icon indicating the need to address the issue at a later time, like when the battery is moderately low.

Likewise, when I am connected to Wi-Fi, the icon changes, as it should. When I need to enter a Wi-Fi password, it is because I am trying to connect to Wi-Fi. That intention cannot happen unless I enter a password. Hence a dialog. The analogy here is that after a system is updated, one can argue that the update cannot "fully" happen unless the user reboots. But this is not true in the sense that the reboot has to happen at that very moment. The system will finish the update whenever the system is next rebooted; hence, the important thing is the user be made aware of the need to reboot. With respect to the Wi-Fi password, the user cannot access Wi-Fi unless they enter the Wi-Fi password. It's something that has to happen at that very moment.

Many of your arguments appear to gloss over or ignore an important principle in Unity design. Of course if someone never shuts down or restarts unless explicitly prompted, shutdown and restart will never occur at the power-cog. But this is a moot point. For someone who only shuts down and restarts from the power-cog, the only place the events occur is at the power-cog. The point is in the conformity to the overall design of Unity. The indicators in the right-corner of the top panel (along with NotifyOSD) is the informational hub in Unity for system-related matters. This is basic Unity design principle. This is where system-related messages SHOULD present. You seem to be arguing that how one particular user may choose to use the system warrants ignoring this design criteria/principle of Unity. If the system needs to be rebooted to accomplish something, this "longterm" state should to be communicated to users via the established Unity design principle of a red system-indicator.

Many people hate popups when Google Docs use them. And they hate them when advertisements use them. And they hate them when they land at a website and the screen grays and there's some stupid popup telling them to "Like" them on Facebook (forcing them to click an X to get rid of the popup). Popups should only present when input is REQUIRED to prevent a change in runlevel or to complete a REQUIRED objective to achieve said state (i.e., something that will disrupt what the user is trying to accomplish at that moment). Other popups are nothing more than nuisances and serve mostly as an interruption. A popup announcing that a reboot is needed may be a permissible exception because it is informational while simultaneously serving as a "shortcut" to accomplish the act. If the user chooses not to reboot, however, repeating the popup-dialog is introducing a nuisance and needlessly interrupting the work of Ubuntu users while simultaneously failing to utilize the proper communication channels that Unity Design Principles stipulate. The power-cog turning red is the appropriate way to handle the communication of the system's state in this regard.