Steps: 1. Add the timer widget (desktop or panel). 2. Assign hotkey to the widget. 3. Select desired time. 4. Press hotkey, big window with digits appears. Result: Timer counting down at double speed.
I have seen this in another project, seems QtQuick Timer isn't that reliable. Should probably be rewritten to use a QElapsedTimer.
I have the same problem at openSUSE 42.2.
Two days left to official ubuntu 18.04 release and this bug is present in kde.
QtQuick's Timer became unreliable and is notifying the plasmoid that a second has passed twice each time it passes. I'll rewrite the handling to make sure that's no longer the issue. (And while I'm at it, I'll fix the precision, cause the timer plasmoid really isn't precise, which I wasn't ware of before.)
*If* there is a Qt bug if you can make a tiny test we should submit a report to Qt as well as any workarounds.
Ok, so I've rewritten the timer logic and now the plasmoid is (much more) precise independently of issues with Qt. And fixed a few other bugs while I was at it. So first order of business is getting that code merged. Dealing with the Qt bug, well, isn't really my priority, considering that (a) I don't want to spend the time on learning how to build qt things and (b) if it's not just the qt timer itself, but it interacting with something else in the plasmoid, then it could take a while to pinpoint a test case. Especially for someone who has no idea how to write plasmoids. If anybody in here has a qt dev env and the know-how to use it to do a quick test, then the offending code I'd start with would look something like this: Timer { id: t; interval: 1000; onTriggered: { var ts = new Date().getTime(); console.log(ts); } repeat: true; running: true; } What should happen is a log output roughly every second. What instead happened in my debugging of the plasmoid was two log outputs every second, a few milliseconds apart. Which nicely explains why the plasmoid on my ubuntu 17.10 worked fine, and then got the double boost when I upgraded to 18.04, all the while the code of the plasmoid itself has not changed one bit. Only possible conclusion: the problem must be in the underlying libraries.
Fixes for this bug (and probably 391634) can be found here: https://github.com/mmazur/kdeplasma-addons/tree/timerfixes Anybody willing to get them merged has my blessing. I'll probably try to do it eventually, but likely not anytime soon, since that phabricator thing does not look overly inviting to someone trying to quickly drop a few lines of patches.
It's actually pretty easy, and I'd be happy to walk you through it. The documentation is at https://community.kde.org/Infrastructure/Phabricator Submitting via the web interface is literally a 5-minute process.
Ok, found a spare hour to figure this out (courtesy of car mechanic having scheduling problems). All patches submitted, including the one that fixes this issue (D12536).
Thank you!
I got the same problem - timer skips uneven numbers.
same problem
Upstream reviewer went silent two weeks ago without making a decision (https://phabricator.kde.org/D12536), so anybody interested in having this applet working can patch it themselves (no rebuild needed), though out of the box it'll remain broken for the foreseeable future.
(In reply to Mariusz Mazur from comment #13) > Upstream reviewer went silent two weeks ago without making a decision > (https://phabricator.kde.org/D12536), so anybody interested in having this > applet working can patch it themselves (no rebuild needed), though out of > the box it'll remain broken for the foreseeable future. There are outstanding change requests for you. We appreciate the patch for sure, but the purpose of the review system is to allow patch submitters to receive and act on feedback from reviewers. It's not just a rubber-stamp. If you're interested in your patch being accepted, you'll need to act on David's change requests.
My last comment contains a proposal to work around the issue pointed out by the reviewer. And I end with: "(…) I'm waiting to know how you'd like to proceed on this patch and the other one.".
A friendly ping with a "How would you like me to proceed?" might do the trick.
I don't think this is a bug of QtQuick `Timer`. IMO the problem is a duplicate creation of `TimerView` and therefore duplicate timer trigger. If I remove/comment out e.g. the second (main.qml, line 60): `Plasmoid.fullRepresentation: TimerView { }` the counter works correct. Adding a third `TimerView`, the counter jumps three seconds at once. I'm not familiar with QtQuick so I'm not sure what the best solution could be, maybe moving the timer from `TimerView` to `main`?
Peter, since the original patch seems to have stalled, would you like to submit one based on your findings so far?
Peter's observation had been good, agree that this is the issue Patch up for fixing this issue at https://phabricator.kde.org/D13065
Git commit 6ce58880151dad9e0adb3607087de12bca65a6cc by Friedrich W. H. Kossebau. Committed on 23/05/2018 at 15:41. Pushed by kossebau into branch 'Plasma/5.12'. [Timer applet] Fix double speed countdown & commands run multiple times Summary: Both the compact and the fullpresentation variants of the applet had an instance of a timer, and both were connected to the central "running" flag. So if both variants had been created, there were 2 timers triggering the decreasing of the seconds, and also firing off the command once done. Moving the countdown timer (and at the same time also a timer for delayed saving of the state, which had the same issue) to the central root item fixes this. FIXED-IN: 5.12.6 Test Plan: Applet still works as before on panel and background pane, now does proper countdown in both cases. Reviewers: #plasma, davidedmundson Reviewed By: #plasma, davidedmundson Subscribers: davidedmundson, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D13065 M +0 -43 applets/timer/package/contents/ui/TimerView.qml M +41 -0 applets/timer/package/contents/ui/main.qml https://commits.kde.org/kdeplasma-addons/6ce58880151dad9e0adb3607087de12bca65a6cc