This change adds a linear progress bar to the top of the user's screen. 2 bars are shown to indicate how much time is left. This feature can be turned off and is configurable (colors & line height in the RSI break configuration app.
Details
Details
- Reviewers
aacid
Program should build successfully.
In the RSI break notification icon, click Configure RSIBreak. Under General Settings a section called Linear Progress Bar Settings should be shown.
Enable "Show Linear Progress Bar"
The linear progress bar should appear at the top of the screen within 3 seconds (typically, though, after 1 second) and should progress down to a length of 0 for each break.
Change each color for SHORT break and LONG break. The colors of the progress bar should reflect the ones specified in the configurations.
Change the height of the progress bar (note this is the height of *each* progress bar, not the total height of both). The total height of the progress bar should be equal to 2 x the specified height.
Uncheck "Show Linear Progress Bar." The progress bar should disappear within 3 seconds.
Check "Show Linear Progress Bar" again. The progress bar should reappear with the configuration the user specified.
Quit RSIBreak. Restart the application. The progress bar should appear at the top of the screen using the configuration values the user specified.
Diff Detail
Diff Detail
- Repository
- R368 RSIBreak
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Comment Actions
is KColorButton something you can use instead of your button color?
Is this feature really painting two lines on the top of the screen? Seems a bit hardcore 😄
Comment Actions
First of all, sorry for the delay; hate to leave fellow devs hanging!
I remembered coming across KColorButton as a widget one time. This time around I hadn't found any relevant documentation or library source code. Anyone on StackOverflow wanting a color button in KDE development was promptly given a R.Y.O implementation. If you know of any existing lib, please forward me the link.
Is this feature really painting two lines on the top of the screen? Seems a bit hardcore 😄
Yes, yes it does. Is it *too* hardcore? What I really wanted to do was make the "non-painted" area transparent, but after hours of hacking and scouring forums it seemed unlikely that Qt can do such a thing, so I just opted for semi-transparentness. If you know of a way to make this possible, please tell me.
Comment Actions
Why would you use stackoverflow for questions about KDE development instead of the kde channels?
https://api.kde.org/frameworks/kwidgetsaddons/html/classKColorButton.html
Is this feature really painting two lines on the top of the screen? Seems a bit hardcore 😄
Yes, yes it does. Is it *too* hardcore? What I really wanted to do was make the "non-painted" area transparent, but after hours of hacking and scouring forums it seemed unlikely that Qt can do such a thing, so I just opted for semi-transparentness. If you know of a way to make this possible, please tell me.
Honestly i don't see what this feature adds, why do i care how much time is left until the break so much that i need to have it permanently on screen?
Comment Actions
I was doing my own Internet search for the answer, and there seemed to be nothing on KDE forums. StackOverflow just popped up a lot. I suppose I should have asked it myself.
https://api.kde.org/frameworks/kwidgetsaddons/html/classKColorButton.html
Is this feature really painting two lines on the top of the screen? Seems a bit hardcore 😄
Yes, yes it does. Is it *too* hardcore? What I really wanted to do was make the "non-painted" area transparent, but after hours of hacking and scouring forums it seemed unlikely that Qt can do such a thing, so I just opted for semi-transparentness. If you know of a way to make this possible, please tell me.
Honestly i don't see what this feature adds, why do i care how much time is left until the break so much that i need to have it permanently on screen?
If this isn't an issue for you, that's fine. I'm using my implementation from day-to-day and finding my break times are a lot less jarring.
Like most developers and creative types I can tend to get so focused on what I'm doing that it's hard to get a sense on how much time has passed. The ProgressBar can give a visual hint as to how much time is left. Because, for me, if I don't have a constant indication of something, that thing doesn't exist. Then when it pops out of nowhere I have to remember, "oh, yeah, I set that...to take a break...but--my current task!"
It follows the same approach as the time timer.
If it's not what you had envisioned for the project, I apologize. You don't have to commit it. However, I was hoping you and others would find the benefit of it. In any case, thank you for at least considering this feature.
Comment Actions
No need to apologize
You don't have to commit it. However, I was hoping you and others would find the benefit of it. In any case, thank you for at least considering this feature.
I'm not saying it's not useful for you, obviously otherwise you wouldn't have coded it, my problem is that i have to think about long time maintenance and also the repercussions of this feature, once this get in, some people will start asking for it to be in the bottom or in the left or in the right, and why not a circle in the top right instead a bar. Which again only increases maintenance costs, which is fine if the vast majority of the users use the feature, but if it's a very small number it doesn't seem to be a good investment of time very scarce time.
So i don't know what to do from here, rejecting your contribution is not a nice move, but accepting it puts me in a path to a possible reasonable increase of work or people unhappy because their suggestions are ignored :/