When KWin crashes several times in quick succession it disables compositing for safety.
However, when this happened, it leaves the user without compositing without any idea what was going on, other than "my windows look ugly now".
This patch stores the fact that compositing got disabled because of crashes in the config and shows an appropriate icon which opens the Compositing KCM which then also has an explanatory message.
Details
- Reviewers
davidedmundson - Group Reviewers
KWin VDG
- Called killall -SIGSEGV kwin_x11 serveral times in a row
- KWin restarted with compositing off and I got a try icon
- Clicked the tray icon, acknowledged the message, re-enabled compositing, icon went away
When I uncheck "enable compositing at start" KWin reconfigures but doesn't disable the compositor. Not sure if this is caused by this patch or not.
Open to suggestions on wording
Diff Detail
- Repository
- R108 KWin
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Wouldn't it be better to have something like CompositingDisabledReason rather than CompositingDisabledAfterCrash in long term?
UX-wise, I wonder whether an SNI alone is the right thing to use here. In my experience many users don't actively monitor their system trays for new icons, and only notice these kinds of events when there's an actual notification. Discover for example uses both an SNI and a notification, with the SNI just being there to provide a handy link to Discover after the notification times out or closes. Maybe we should do the same thing here too.
Wouldn't it be better to have something like CompositingDisabledReason rather than CompositingDisabledAfterCrash in long term?
Ack. But that can be a separate task.
As for the notifications in addition to a system tray icon, I think it makes sense to start light and build changes up. Currently we do nothing, we can always expand.