My name is Cort Johnson, and I am currently working on a modern version of TagTime which can store and retrieve your ping data in the cloud. I am looking for beta testers in order to improve the functionality and usability of this new version, and it seems like this forum is the perfect spot!
As of right now, the application is easiest to setup and use with Windows, as all you need to do is download and run the setup installer found on the GitHub.
NOTE: This program is currently in beta, therefore the setup installer isn’t currently verified by Windows, however if you are concerned about security risks, the entire source code of the program is in the main repository.
I am mainly looking for people to test out all of the features for this new TagTime program, and since I’m not too familiar with Linux, I am also looking for help on what is the best process I can take to make the setup and installation as easy as possible for Linux as it is mainly a GUI application, and shouldn’t be ran with a terminal open along with it.
Any feedback is appreciated, and I look forward to hearing from all of you. I am heavily invested in making this the best it can be, so anything that needs to be done, I can do quickly.
Also, if you just have any questions in general, feel free to ask!
Beeminder Integration - have the ability to point tags to a certain goal, and each ping including that tag gets added as a datapoint!
Added Support for Mac OS
Task Editor - have a preset string of tags and/or comments that can be attached to a number, using that number as a tag in a ping will replace it with the whole string!
General Bug Fixes and adjustments to Program Logic
Original VIM Macro for quickly changing old logs implemented into Log Viewer/Editor
Now takes any old TagTime log and fixes the formatting, any old log is compatible with this version.
I’m currently working on getting both the windows and the mac builds signed so that there will be no more security warnings, as I understand that’s probably a big thing before anyone should download it.
I think I’m gonna try to change things up a bit since it’s been a month since I initially made this post and not a single beta user
Instead of using executable’s and setup installers, it makes more sense that since we are regression testing, anyone who is interested in testing out this program should run the python script by itself without using any sort of executable. Once I’m happy and we have a “final” product, then I will compile everything into executables, get certificates to sign them, and then put the application onto the App Store, and the Microsoft Store, and then most likely also including the setup installers on the GitHub.
I’ve added a “Mac” folder to the repository, which includes all of the proper resources for that operating system, so if you are on Mac and want to try it out, you would use the files in that folder. Here are the installation steps:
Windows:
Make sure you have Python 3.8+ installed
Press the green button at the top of the repository that says “Code” and then Download ZIP, alternatively you can clone the repository.
Install the required libraries by doing: pip install -r requirements.txt
Run tagtime.py
MacOS:
Make sure you have Python 3.8+ installed
Press the green button at the top of the repository that says “Code” and then Download ZIP, alternatively you can clone the repository.
Open up a terminal, cd into your TagTime folder, and then cd into the “Mac” folder
do “pip3 install -r requirements.txt” or “pip install -r requirements.txt”
After the libraries are installed, do “python3 tagtime.py”
Linux:
Same as Windows
With that said, I would like to ask anyone who is interested in trying out this version of TagTime, is there something you would like me to do before you try to install it? Anything I can do to put your minds at ease or to help with the process, please just let me know as I am trying to get as much feedback as I can for this program, and I haven’t been able to get any yet
I will say this, I have been running this version of TagTime on my PC for a few weeks now, and as far as I can tell I haven’t found any problems with it, and everything in regards to Beeminder integration works smoothly.
Yay! Thanks for all the work on this. I’m excited to try it. I’m running into some trouble though, on macOS:
$ pip3 install -r requirements.txt
error: externally-managed-environment
[...]
$ pip install -r requirements.txt
Collecting certifi==2024.7.4 (from -r requirements.txt (line 1))
[...]
[seems to have worked]
$ python3 tagtime.py
Traceback (most recent call last):
File "[...]CloudTagTime/Mac/tagtime.py", line 9, in <module>
import pystray
ModuleNotFoundError: No module named 'pystray'
I’m guessing I need to do the pip3 instead of the pip thing? ChatGPT is telling me I need to use a virtual environment (I super don’t want to deal with that though) or else use the “–break-system-packages” flag, which sounds dangerous. Not that I have much faith that ChatGPT knows what it’s talking about.
Are you sure you have the requirements.txt file in the CloudTagTime-main folder?
Are you able to open up the entire folder in visual studio code and see requirements.txt and whats in it?
Honestly the only thing I can think of is that you maybe didn’t extract the zip, so you are trying to access a file that isn’t extracted? Not entirely sure, if nothing is working to install requirements.txt, are you able to pip install each individual library?
Well, the file was definitely in the same folder and unzipped
I was able to install the libraries one by one mentioned in the txt. Now running it and trying other things, will report more impressions later!
Great, I have some impressions now.
First of all, after that glitch with the requirements text file, I was able to run everything without problems. No further glitches discovered
But here are some thoughts:
I was able to connect a test tag to a test goal in beeminder, works well! But it looks like the datapoint value sent to beeminder doesn’t take into account that the ping frequency might be set to something different than “every 45 minutes”. I have it set to 15 mins, but the data sent to beeminder is still 0.75 per ping.
Do I understand it correctly that the plan is to have the app refer to the same database across devices and platforms, so that pings can be answered on pc or phone all the same? Would it be possible to put the pings on the same universal schedule with the currently existing tagtime app in the meanwhile?
The countdown in the terminal - is it just for temporary debugging purposes, I hope? With tagtime, not having any way to know when the next ping comes is an absolute dealbreaker.
Adding a silent mode is something you might want to consider. Just silent with still appearing pings (use case: I am on a call) and/or a mode when pings are temporarily disabled and responded later (use case: I am showing my screen in class).
Thank you very much for working on this! I hope these suggestions don’t look like too much criticism, there’s unfortunately a tendency to go to the “now, this doesn’t work and this needs to be improved” mode instead of acknowledging the tons of work that have been done. And I really appreciate the work that you put into this. I would be really interested in such a cross-platform version of tagtime, as I have found myself being distracted by the proximity of phone so often when the only reason to keep the phone in proximity is that I am responding to pings.
I have updated the GitHub for both builds in regards to the following:
I have changed the value from always being 0.75, to now being related to what you have set for your gap. IE a 15 minute gap is now worth 0.25, while a 45 minute gap is still 0.75
Added a silent option to the ping sounds, you can select this if you don’t want any sound to play.
Also added a Silent Ping option, turning this on will result in the ping never actually coming up on the screen. With the option turned on, any ping that is “silenced” will be given the tag “silent”. Feel free to edit it easily afterwards in Log Editor.
Correct. I have left a majority of my print statements in the code for debugging purposes while we test. The final build will have no print statements, better yet, since they will be fully fleshed out applications, the application won’t even have a terminal. All you will see (when you don’t have a ping open or any of the other windows) is the task bar icon. For windows you will view this by clicking the up arrow on your taskbar in order to quit the application, or to go to settings or log editor (already implemented). On Mac, this taskbar icon is always visible, but with no terminal.
How it works right now is this:
You have your log.log file saved on your computer, when you answer a ping or edit any logs, your entire log is copied over from your pc, and saves it in a google cloud storage (assuming you are logged in with google). If you were to move to a different computer, you can login to TagTime, and export your log from the cloud, and then replace the new file you get with the log.log and you have transferred over your cloud-saved logs successfully. There are flaws to this, as if you were to move to a different PC with an empty log, download TagTime, sign in to google, and then answer a ping without replacing your log file, your cloud-save will get overwritten with a near empty log.
I can see how it would be ideal to have a universal database, where your log file is constantly being synced with the cloud-based one, and instead of overwriting the entire file it would be adding on top of it. But I would need more input from others to see what the best system would be for this before I implement anything.
In regards to the universal schedule, I’m not entirely sure if it is possible to get the exact same as the current existing one, as python’s random function uses the " Mersenne Twister algorithm", while perl uses the " Linear Congruential Generator (LCG) algorithm". I haven’t researched this enough to see if I can implement the exact same algorithm used, could be possible though. For right now, I am still using the same start time and seed that the original perl scripts use, but since the default algorithms are different (or it might even be because of my math) the schedules are different.
With that said, this version of TagTime should be within it’s own universal schedule as of right now, so the timing of a ping on one windows computer would be the same on another windows computer, but this also needs more testing.
A question I have regarding this would be:
If you have a phone and a PC both using TagTime, and both are on the same database (logs are synced to eachother), and are both on the same universal schedule, how would you expect the double ping behavior to be? As you would be getting two pings at the same time, both going to the same log database.
Thank you very much for so promptly implementing the suggested changes! I will download the new build and try them out in a moment.
And thanks for the explanation of the situation re: universal schedule.
Ideally (ideally! in an imagined perfect world), everything would synch immediately, so as soon as I answer the ping on PC, the app on the phone also has the same response entered.
But in fact, despite all my intentions, I have never used tagtime for QS purposes, so having everything in a perfectly aligned database is not a must for me. If the PC app and the Android app just behaved in the same way (sent the same format of data to beeminder[*]) and worked on the same schedule, that would work perfectly for my aims. I primarily use tagtime pings to measure the time spent on one project, which includes both writing/reading on the PC and reading on my e-reader or paper books away from the PC. I would simply respond the ping on PC when on PC and benefit hugely from not having the phone at hand, and then respond on the phone when working on project-related things away from the PC. I don’t imagine I would cheat by double-responding the pings on different devices.
Or did I misunderstand your question?
[*] by “same format” I mean the fact that your app does this wonderful auto-summing, while the official tagtime app for android sends separate datapoints for every ping. Since my current setup is based on the official android app, it builds off the separate datapoint system.
I’m confused on whether you prefer the auto-summing format or the single datapoint format.
What I mean by the double pings (this only applies if the logs are synced) is that, if you have two devices signed in to the same account, you would always have two pings, with the exact same timestamp, for every 1 universally scheduled ping.
So say you are at your PC, and you have your phone nearby. You get a ping on both devices, and since you are probably using your PC at the time, you answer the ping there, and ignore the ping on your phone. Your logs would now have two new pings, one that you actually answered, for example “tag (comment!)”, and the one that you didn’t answer, which would be “AFK Retro”. In any case, whether you answer both pings, or only answer one, you will ALWAYS have two pings that have the same timestamp. I was asking how you would expect these situations to be reflected in the synced log, because this is how I would expect it to behave.
I find your auto-summing format sleeker and more user-friendly in the resulting log of datapoints at beeminder. However, because the official android app currently sends separate datapoints, my current setup depends on that. I just meant that before I could incorporate you app into my system for real (rather than just try it out to help debug), there needs to be compatibility on this side as well, in addition to universal schedule. I mean, I am just jumping ahead and thinking of how to use it for my purposes together with the current official android app, rather than wait for your android app. Just thinking out loud to help account for potential use cases.
Yes, I think that would be good enough. I do not see any problem with there being two of them if it doesn’t create loops with data being sent to beeminder. Unless the logs are used for some QS analysis of where the time went, there should be no issues with the double pings at all, and if they are used for fancy QS analysis, it should be pretty easy to account for the multiple pings with the same timestamp in the code that will analyse the logs.
I am testing the new build right now. Works great, both silent modes work as expected. And the fraction of an hour is now sent to beeminder correctly.
A quick potential UVI: in the settings when I enter the tags to match the goals, the tags are expected with commas in-between, while in the ping interface, they are expected with spaces in-between. (Is it true? That’s what ended up working for me after trial and error.) I would suggest - spaces in both cases?
Yes I forgot to update that! Initially I thought pings were seperated by commas, and I had the tags pointing to goals using the same format. Guess I didn’t update that menu when I ended up switching to using spaces to seperate tags. Will update that when I wake up as it’s a very easy fix.