hgkamath
commented
1 year ago I was trying the app out, just some feedback
- perhaps projects can be hierarchical
- perhaps some tasks should be pre-definable for each project
- ~perhaps tasks with same taskname but different projects should not be shown as clubbed together.~ ok, I learnt I had to press the check-sign for a task-conf-edit change to persist.
- A problem with the check or export overlay button is that it obstructs reading the last line of the activity-window. The button isn't movable. I prefer a save button on the top bar (next to where the search/delete/filter icons are), that starts out as greyed, but when something is edited/modified it becomes enabled/stands-out indicating that dialog has changed properties, and needs to be saved. A modal popup to discard changes when hitting back also confirms whether user does not wish to save changes.
- Presently a task definition seems to be inferred from previous task history. An alternative is to pre-create task-definitions and select project/task. While ad-hoc creating task names is convenient/easy, its also easy to mistype and create naming errors, [Edit] I just discovered that there is a autocomplete drop-down.
- Another disadvantage of having each entry be its own task-definition with properties is that, here the task description itself is its name. If I change the description(name) for a task, it does not change it for the other task-items that still have the same description. Tasks are distinguished by the description/name itself.
- Some properties might be specific to a single run (ex notes, start, stop), some properties (description/name) could be be common
- Not, separating task-definition from task-entries has implication for export, archiving and deleting. Suppose after exporting and archiving a time-range of task-entries, I delete them, essentially I lose the definitions as well. Hence, I need to keep old task-entries hanging around if only for definition and quick-access sake. If task-definitions were separate, there is no less when expunging old task-entries.
- I suspect the reason why task-definitions are not separated is so as to avoid having to de-normalize relational-tables, using projectdefID, taskdefID, taskentryID .
- Track untracked time from a starting date/time.
- This is not the same as having a task permanently running
- Stopping and starting a second task to track non-task time in order to get "untracked" time is painful.
- Report view shows only pie chart of selected (by default all) projects.
- Also useful:
- un-clubbed pie-chart, this shows the fragmentation of tasks
- un-clubbed pie-chart with untracked time, this shows the fragmentation of tasks and the unused time between task fragments
- day/week/month view with task-blocks linearly colored according to project. This also shows the un-tracked/un-used time.
- Also useful:
maybe I could get used to it. (I am used to https://github.com/kromitgmbh/titra/)
As a flutter/dart app this should not be too hard. and one shouldn't expect users to make the build themselves.
Some users prefer an app, that runs on multiple devices/OS with distributed ready to run builds That's the whole selling point of dart/flutter.
PWA/Linux/Win/Mac/Android/IOS/self-hosted A scoop manifest for automated updates is also desirable.
A PWA can eliminate the need to install a app locally onto a device. The PWA runs in the browser. By default saves data to browser-appdata. Optionally one should be able to save to cloud storage. Selfhostability allows the PWA to be made available by a local instance of a https server.
ps. thanks to developers for making this app.
Having seconds thoughts on windows build: