Main Area and Open Discussion > General Software Discussion
Looking for a very flexible timer
Edvard:
I like version 2 for layout, though I wonder if it was a typo that the task-begin-end-total bar was left out?
It just seems we're so close to everything, because if there is a "stopwatch mode", then it can start with a timer of 0, start-stop works as normal, and "lap" creates its own "pseudo-tasks" aka the laps breaking down the segments of each task, below the main header of it.
It feels to me like this should be easy ... but famous last words?
-TaoPhoenix (May 04, 2015, 03:28 AM)
--- End quote ---
Umm... yes. :stars:
... and I have no idea what happened in the screenshot for #2, but yeah, I like that layout better too. I may even have some ideas for a 3rd, but first I think I need to simply get the main stuff happening and get some feedback from Tomos as well.
Onward!
tomos:
Umm... yes. :stars:
-Edvard (May 04, 2015, 09:13 PM)
--- End quote ---
;D you're doing great :Thmbsup:
Re: layouts
both look good there - but #2 is preferable I think - and more foolproof too :up:
tomos:
I notice:
* create, say, three tasks - without using reset (let each run for a time before creating the next)
* then create a fourth task - it will show the endtime of task #3 in the timer
* try Reset on task #4 - it reverts to endtime of task #2should it not simply reset to zero? (again, I may be missing an application)
-tomos (May 03, 2015, 04:49 AM)
--- End quote ---
If my logic is correct here, if the fourth task has not been started yet, it may (should?) reset to the beginning time of #3, which is the ending time of #2. Once the fourth task has started, reset should simply reset to the beginning time of #4. Sounds like I really do need to implement some choices and defaults like "Start new tasks at zero/Continue from previous."-Edvard (May 04, 2015, 01:36 AM)
--- End quote ---
I'm still confused by the above:
-I'm not sure *why* would the user want it to revert to the beginning of task #3 in the example above? (Even if it is logical in terms of how it works.)
So, a group of tasks can ultimately be treated as one task, simply by looking at the end time of the last one.
IF I can revert a new task to zero, it would have to be the start of a new group - this would be a great feature - but I dont know if it's possible (?)
+
Another feature could be to add a new task below the current group - i.e. I could add a new task to group #one, even after having created (and run) a second group. This could cause user-confusion though :-/ and again I have no ideas about difficulties of implementation. What do you think?
tomos:
Maybe this is not yet implemented:
tasks are not saved on closing.
___________
If a timer is active and already stopped/started again - I find the display confusing:
* I see the end time in the timer
* I see start time and previous end time below
* I see previous total below
I cannot at a glance see:
* how long I've been working on this task in this session
* and how long I've actually been working on this task in total
I'm wondering, would this help
* show the end-time slightly greyed when task is active - I suspect this would also have to be refreshed though, in oder to refresh the total time (?)
* the total time gets refreshed (every second?)
Edvard:
both look good there - but #2 is preferable I think - and more foolproof too
-tomos (May 05, 2015, 03:41 AM)
--- End quote ---
#2 it is... I'll roll with that. Though how it is in the screenshot probably won't be the final final form.
I'm still confused by the above:
-tomos (May 05, 2015, 04:00 AM)
--- End quote ---
I admit it is confusing, but all I was saying is that if task #4 has been initialized, but not started, then the value that remains stored in the Reset variable is the beginning time of the previously active task, so that explains the behavior. Bug? Yes, that should count as a bug. But I'm left wondering what should be happening. Should hitting Reset at the point after a new task is initialized set the start time to Zero? Or the end time of the previous task? (Actually, I have an idea; more about that farther down...).
So, a group of tasks can ultimately be treated as one task,
...
I have no ideas about difficulties of implementation. What do you think?
--- End quote ---
Task grouping sounds like a great idea, but I am at a loss as to how to implement it. For now, anyways...
Maybe this is not yet implemented:
tasks are not saved on closing.
--- End quote ---
Whoops! Time to implement auto-save, or a reasonable facsimile. Should it ask the user to confirm on exit? Or simply save the session with a possibility to recall on the next start-up? Or a set-able option to automatically load the previous task list on start-up? So many possibilities...
OK, so with most of the internal logic pretty set, here's what I'm thinking for the next iteration of user interaction:
New Task:
- Make a toggle for "Start at Zero" or "Continue from Previous".
Reset:
- Reset should always reset to the beginning time of the current task, whether that is zero or something else depends on the New Task behavior.
OR...
- Make "Continue from Previous" the default 'New Task' action, but "Reset" will set the clock back to zero. Much simpler code that way...
Timer:
- I don't like the idea of the end time updating in the list, I mean, it's not even there until you stop the timer, so I think "graying out" the end time and total when re-starting a current task is a great idea; takes your mind off the list and back on the timer, and also lets you know at a glance that this is a task that has been continued. Which leads to...
Tasks:
- Going back to an old task to continue the time spent on it is a good idea as well. I know how it can be done, so that'll be in the next iteration.
- Grouping tasks isn't as easy, maybe even impossible without a custom component. The StringGrid component has a lot of methods and properties to it, and is quite complex. Trying to wrangle sub-lists into it would be problematic at best.
Sessions:
- Saving sessions should be a given by now, you're right; not saving the session is kind of unsettling. But how to implement? I'm thinking either offer the user to save the current session on exit, or simply auto-save and have an option to auto-load on next start-up. That will be easy to do. Hmmm... maybe even differentiate between saving a session and saving a final file; kind of like: if saving a session, then auto-load the session on the next start-up, but if saving a final file, the next start-up is blank. You can always manually load a saved file from the File menu and continue as well.
So that's what I got, I'm going to dive back in and get something ship-shape for you to test, hopefully not too far in the future. I'll keep the thread posted with any breakthroughs...
8)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version