Proper, Consistent Backgrounding

Registered by Cassidy James Blaede on 2012-11-27

We should implement and encourage a proper, consistent, and well-worked-out method of backgrounding. Currently each app is on its own to decide how to do backgrounding, but we should lead by example as well as provide a few nifty features for apps.

Currently we have bugs like this:

Bug 1083429: Show which apps are still doing things in the background before shutting down
Bug 1083428: Continue downloads in the background when the window is closed
Bug 1083306: Continue tasks in background when window is closed

But it's not consistent or clear as to how the app should implement it. We should define how it should be implemented and, where neccessary, provide things to the apps on an OS-level to get it done.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
elementary UX
Direction:
Needs approval
Assignee:
None
Definition:
Drafting
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Whiteboard

The way Noise handles this is interesting: When closed, it actually minimizes if there's music playing but closes if there's not. This might be a step in the right direction, but it gets weird. For example, if I play some music, "close" Noise, then stop the music later, Noise is still open even though I told it to close earlier. Also, the icon stays in the dock whether or not I pinned it there. Apps that support background processes (like old-school Postler) close the main window, but leave a daemon in the background. An advantage to minimizing-instead-of-closing could be that we get dock badges and progress bars for free this way. Would we then close the app for real when that process is complete? Either way, we need to define "the right way" for it to be handled. Another issue to look at is what happens to a "closed" app that's still doing things in the background when we go to shut down. We could implement https://blueprints.launchpad.net/elementaryos/+spec/shutdown-when-complete and/or fix bug 1083429 to help with that. Discussion more than welcome. ;) ~cassidyjames

Expanding on the previous blurb is one proposed method of backgrounding: "If an app is performing a task that can be performed in the background (i.e. without the window being open), then when closed, it should actually minimize. The app should provide information to the user via LibUnity if applicable. When the background process is complete, the app should show a notification that the task is finished, then close completely. When shutting down, the OS checks for any apps that are still open and attempts to close them normally. If they minimize, the OS assumes they are performing background tasks and alerts the user, allowing them to switch to the app or force a shut down." Basically this hijacks minimize as a sort of backgrounded mode which has the awesome advantage of being bult-in, but the (smaller) disadvantage of being inconsistent with other platforms. Feedback and refinements are welcome. ~cassidyjames

I think in the case of Noise, we definitely need it to be a daemon since it needs to be able to perform other tasks without opening the window such as syncing. --DanRabbit

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.