Closed srguiwiz closed 3 years ago
Now I recognize that flood of zero length entries while idle, one every twenty seconds, may only be in the UI of showing entries, but not in the database.
I found out because after quitting the application UI, killing the process, uninstalling one build and installing another build, then only the good time spans show in the list for that day, from the earlier run.
Updated issue above because the guess with <= 30
was not useful. The problem is with the UI showing zero length entries.
The workaround is killing the process, for example with pkill timeit
or if you are more cautious with pgrep timeit
and a kill
. When launching TimeIT again, then one can read the actual time spans worked.
Quitting the application UI is not enough to achieve the same goal.
low/zero length time spans can occur by different reasons and are removed at next start. Please continue searching, maybe you find out what is happening.
Would be awesome if it removes them when opening a detail view, so the user would be able to report when they worked.
Maybe more efficient to not even enter zero length entries? 12 hours of a machine sitting idle could be 2160 zero length entries.
Additional note: The zero length time spans ARE in the database as the UI is "always" showing what is in the database. The exception is before committing something manually edited..
Would be awesome if it removes them when opening a detail view, so the user would be able to report when they worked.
Maybe more efficient to not even enter zero length entries? 12 hours of a machine sitting idle could be 2160 zero length entries.
Yes, I agree and I think that something is really wrong as I have not observed the behaviour. It did happen before when moving between workspaces.
I think that closing a time span should also check if it is of a reasonable length. You should look in TimeKeeper.cpp and see how it handles it
Question 1: Do you think you could comment some of the code, for example in IdleDetector.cpp
, so it would be somewhat easier for an additional person [yours truly] to work on this problem?
Not trying to get you to do "real work", rather thinking you may recollect what you thought certain code, conditionals, etc. were meant to do, and if you put it into comments that would make it easier to debug now.
I appreciate what this application does. Simplicity is a virtue.
Question 2: Are you using a specific debugger or IDE? I am embarrassed to say, while that used to be my forte, I haven't on this platform for this programming language, so I am wondering in case you do, which one?
In case I don't keep up debugging this, I have come to live with the workaround. But, I would read newly commented code.
Answer 1: Yes, I can maybe comment some things but I think that it is probably better that I write the code so it is clearer instead.
Answer 2: I am using CLion at the moment and was before using Eclipse.
We can also have some closer sessions and do some pair programming if you like. I am using Discord for my hobbies so you could join there. Invite: https://discord.gg/MV6YEnRC
Great. I can agree. I avoid committing to a specific schedule at this time.
Meanwhile I have submitted a PR that fixes an obstruction in the installation process in Ubuntu 20.04.
If you annotate IdleDetector::pollStatus()
with comments I could do some more thinking or experimenting when I get to it.
Problem is identified. Working on a redesign.
For the record, the problem analysis has been, as observed in version 2.0.1: In Controller::on_idleDetected()
when satisfying if (quiet)
a call to on_action_revertAndContinue()
causes a twenty second cycle; in which ten seconds each are alternating states, one state starting after IdleDetector::pollStatus()
satisfying enabled && idleSeconds > idleTimeout
causing isIdle = true
, the other state after on_action_revertAndContinue()
via timeKeeper->enable(true)
via IdleDetector::reset()
causing isIdle = false
.
Therefore this would only occur when using Quiet Mode, and only would become annoying if trying to look for time spans in Show Details.
As mentioned, as a workaround, a flood would be cleaned up on an application restart, either a machine restart or a kill of the timeit
process and launching it again.
After or while investigating issue #22 I decided to run a build from master in Ubuntu 20.04. That is more satisfactory.
There is however, a specific problem.
Have set quiet. For testing, have set idle to three minutes. Then, when idle the list gets flooded with three entries per minute, apparently zero length.
The usability problem are hundreds of those zero length entries between the few actual work entries. The total work time shown is right, but one couldn't easily read "from when to when did I work". And also it floods the database with useless zero length entries.
As I'm looking at
IdleDetector.cpp
I see a lineif (idleSeconds < 20)
and that matches the three entries per minutes.[updated strikethrough because wrong]
So far that is factual reporting. Now I am starting to guess, please let me know if right or wrong looking there: I am looking atif (now - lastPoll > 30)
and am wondering whether that should be<=
. I will try that in a build. But I thought I'd report what I found so far, in case you recognize the actual problem faster than I can.Getting this to be usable in Ubuntu not only serves a purpose for me immediately in itself, but also as a stepping stone towards maybe then figuring CentOS 8.