Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFE] Self-hosted, PWA and windows builds #116

Open
hgkamath opened this issue May 27, 2023 · 1 comment
Open

[RFE] Self-hosted, PWA and windows builds #116

hgkamath opened this issue May 27, 2023 · 1 comment

Comments

@hgkamath
Copy link

hgkamath commented May 27, 2023

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:

  • Your intention is to perhaps enforce users to use the smartphone as a single device to do time tracking, which is good. But no harm in being able to time track from PC also as an option.
    • Perhaps the windows/Mac/Linux desktop apps, could popup a one-time suggestion to do time-tracking on a smart handheld device.
    • One may still want to operate on data and visualize, import, export, sync to storage.
  • Perhaps you want users to use a different app like spreadsheet/calc/excel to visualize/analyze the csv file on computer.
    if that is the case, I see why the desktop-app is pointless.
@hgkamath
Copy link
Author

hgkamath commented May 27, 2023

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.

maybe I could get used to it. (I am used to https://github.com/kromitgmbh/titra/)

@hgkamath hgkamath changed the title [RFE] windows build [RFE] Self-hosted, PWA app and windows builds Jun 8, 2023
@hgkamath hgkamath changed the title [RFE] Self-hosted, PWA app and windows builds [RFE] Self-hosted, PWA and windows builds Jun 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant