Bug 378995

Summary:	Suspended RSIBreak with Hanging Notification
Product:	[Applications] rsibreak	Reporter:	promike1987
Component:	general	Assignee:	Albert Astals Cid <aacid>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	NOR
Version First Reported In:	0.12.6
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:	https://commits.kde.org/rsibreak/b2870bb352f2efb9b9daee0e779c7b723bb09b76	Version Fixed/Implemented In:
Sentry Crash Report:

Description promike1987 2017-04-20 12:37:41 UTC

I'm sorry, I thought it was better to send only one bugreport than a thousand.
So,

In the case that RSIBreak is suspended during a relax notification, the notification just hangs there. It shouldn't be there.

Example:
Let's say you give a presentation but you forgot to suspend RSIBreak in time, then you have to close RSIBreak in order to get rid of the suspended notification.

Comment 1 Albert Astals Cid 2017-04-21 14:26:00 UTC

Can you take a picture/screenshot of it? 

How do you manage to suspend it while there's a notification being shown?

Comment 2 promike1987 2017-04-21 19:57:08 UTC

(In reply to Albert Astals Cid from comment #1)
> Can you take a picture/screenshot of it? 
> 
> How do you manage to suspend it while there's a notification being shown?

Sure thing, here are some images:

1) https://ptpb.pw/k4rN
RSIBreak prompts me to take a rest

2) https://ptpb.pw/lqDu
Right click on RSIBreak > Suspend RSIBreak

3) https://ptpb.pw/DSES
notification hangs there

4) https://ptpb.pw/LQb4
notification still hangs there

Comment 3 Albert Astals Cid 2017-04-25 21:58:31 UTC

question is, what should happen after you resume it?

Should it bring back the notification? or should it just "skip" the relax time?

Comment 4 promike1987 2017-04-26 08:26:31 UTC

(In reply to Albert Astals Cid from comment #3)
> question is, what should happen after you resume it?
> 
> Should it bring back the notification? or should it just "skip" the relax
> time?

As I noticed, in the case that RSIBreak is suspended, it doesn't take activity into account. I'm of the opinion that it would be better if suspended RSIBreak were hidden/silent than frozen.
For instance; someone is super busy and they can't afford any more time off work, therefore they might suspend RSIBreak for a while. However, they might leave the computer for a while and if they just resume RSIBreak after that, it would make them take a break again. - which might be undesired -
On the other hand, if someone hadn't taken a rest, after the resume they should do.

I don't want to give you a lot of work and headaches. I think it's better if you relax more than skip one. So if the upper idea is too time consuming to carry out then I would say it should bring back the notification where it was left off.

Comment 5 Albert Astals Cid 2017-05-02 13:47:10 UTC

I'll go with just reshowing the notification since this seems like very corner-case to really spend much effort in making it perfect.

Comment 6 Albert Astals Cid 2017-05-02 13:56:26 UTC

Git commit b2870bb352f2efb9b9daee0e779c7b723bb09b76 by Albert Astals Cid.
Committed on 02/05/2017 at 13:56.
Pushed by aacid into branch 'master'.

Show/hide the notification when suspending/resuming

M  +13   -1    src/rsirelaxpopup.cpp
M  +5    -1    src/rsirelaxpopup.h
M  +1    -1    src/rsiwidget.cpp

https://commits.kde.org/rsibreak/b2870bb352f2efb9b9daee0e779c7b723bb09b76

Comment 7 promike1987 2017-05-03 08:32:03 UTC

(In reply to Albert Astals Cid from comment #5)
> I'll go with just reshowing the notification since this seems like very
> corner-case to really spend much effort in making it perfect.

That's okay.
Having been fixed, rsibreak is working great now!

Thank you!