Review Request 126515: [DrKonqi] RFC: Support showing a StatusNotifierItem instead of bringing up the dialog right away

Kai Uwe Broulik kde at privat.broulik.de
Sun Dec 27 13:30:56 UTC 2015



> On Dez. 25, 2015, 4:37 nachm., Kai Uwe Broulik wrote:
> > Usability: I envisioned this to be used for auto-restarting shell services and not to be used by applications.
> > Another interesting thought could be enabling this by default for all applications but for regular applications trigger a desktop notification (with report bug / restart app) together with the tray icon.
> > 
> > Mockup: http://wstaw.org/m/2015/12/25/drkonqipassive.png
> 
> Heiko Tietze wrote:
>     If I understand right the auto-restart notification does not have any restart button (which wouldn't make sense) but just the report bug interaction. When the user is presented with either restart or report in case of regular apps, and the notification disapears when the button is clicked, he or she would likely rather restart than going through the debug dialog (that usually lacks on debug info). Simple solution is to show the SNI with restart option only. And even more simple is to leave the crash handling to the app.

There will be no auto-restart notification, just an SNI. For auto-restarting services there's no need to point out to the user something bad just happened, not that prominent, at least.

For regular apps I should just show the notification and no SNI? Okay.

Unfortunately we really suck at crash recovery, ie. the "Restart App" button will most likely just restart the app with an empty document or something like that rather than continuing where we left off (somewhat related to our broken session restore I guess). I personally have never used the restart button in DrKonqi.


- Kai Uwe


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126515/#review90100
-----------------------------------------------------------


On Dez. 25, 2015, 4:24 nachm., Kai Uwe Broulik wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126515/
> -----------------------------------------------------------
> 
> (Updated Dez. 25, 2015, 4:24 nachm.)
> 
> 
> Review request for KDE Frameworks, Plasma, KDE Usability, and Martin Gräßlin.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> -------
> 
> This adds a new "--passive" option to DrKonqi where it will only show a StatusNotifierItem rather than bringing up the crash dialog right away.
> 
> This can be useful for auto-restarting shell services (like plasmashell, krunner, kded) to improve the perceived quality of the product.
> 
> On Windows RT, for example, the guidelines even explicitly say "rather just dump the user on the home screen than telling him something went wrong, so he can just quickly start the app again instead of being annoyed by an error message". On iOS you also just get dropped on the home screen. Windows desktop shows a "Searching for a solution" dialog which was *the* major annoyance when something crashed, rather than the actual crash.
> 
> Video here: https://www.youtube.com/watch?v=t0ZLs-juYKc
> 
> 
> Diffs
> -----
> 
>   drkonqi/statusnotifier.cpp PRE-CREATION 
>   drkonqi/statusnotifier.h PRE-CREATION 
>   drkonqi/CMakeLists.txt eaeaad4 
>   drkonqi/main.cpp 7cbaae7 
> 
> Diff: https://git.reviewboard.kde.org/r/126515/diff/
> 
> 
> Testing
> -------
> 
> I crashed plasmashell, it restarted so fast that you didn't even have a black screen inbetween, just the panel restarting. Afterwards I got a SNI which opened DrKonqi when tapped.
> 
> The SNI disappears after 1 minute because if you didn't bother to look after it by then, you probably forgot what you did to cause the crash anyway :)
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151227/0f4a4f1a/attachment.html>


More information about the Kde-frameworks-devel mailing list