Handling unsaved changes on logout
Currently, when a session ends (because of logout, a nested compositor exiting, whatever), applications get disconnected from the display and whether or not they need time to shut down or need user input before exiting is ignored. To fix that, there should be an API where clients can
- tell the compositor that it needs to inhibit the session exit, ideally with a reason for doing so ("not shut down yet" vs "needs user input")
- tell the compositor that session exit needs to be cancelled
- be notified when the user wants the session to end, in order to know when to do things like prompting for unsaved work
- get their windows activated, so that the user can handle stuff like "save/discard/cancel" dialogs without needing to manually search for which windows are inhibiting the session exit
Some questions that still need answering:
- should inhibition be tied to a surface? It would make showing the user a list of apps to handle before shutdown pretty easy and solve the activation problem, but an app might also need to inhibit the session while it's "minimized" to the system tray, where a surface isn't ideal.
- should inhibition be held by the application like with idle-inhibit, or should they be asked by the compositor before shutdown? The former could potentially be faster and could prevent data loss in the case an app isn't responding at the time of logout, but I don't know if that works with existing APIs in toolkits
- should cancelling be tied to an input serial? I can't think of a use case where it would make sense to cancel logout without user action