I believe it’s mostly appearance things that will break, per another person’s comment above. I’m planning on upgrading later this week if BTT seems stable enough (I can’t help but feel the last few releases have been a bit flaky) and export then.
If you’d like to start using the preset with v2.6xx right away, I’d recommend trying to either:
Directly import into v2.6xx. If you see weird backwards compatibility issues w.r.t. visual glitches, then remove the preset.
Import into v2.536, quit, then open v2.6xx. The preset should show up correctly in v2.6xx.
Hey, sorry for the lack of updates. I’ve actually been fixing some bugs and improving performance in control strip services, but haven’t had enough time to finish updating the tests. Hoping to push something this week.
I certainly appreciate the update, but please don't apologize! I am just grateful you're willing and able to share your skills in developing these presets (and I'm sure everyone else here agrees). Plus, it sounds like you're working away on them, and doing a properly thorough job of it.
I will say I am kind of excited and looking forward to your update. Despite my other thread about wanting a simpler version, the more I've used and tinkered with BTT, the more I really like your complete workup.
I haven't had much time myself to try your suggestions above, so I'm just continuing to live with my cobbled-together touch bar.
It uses perisistent command line services (basically small macOS apps) that run in the background and only update the Touch Bar when absolutely necessary. The behavior is as close as possible to the BTT-provided widgets.
Most presets just use a scripting language like AppleScript to repeatedly poll and update the Touch Bar. Scripting definitely can work well and is straightforward to implement and modify, but it comes at the price of battery life impact (usually around 1 hour reduction). Additional empirical data here: (Updated) Testing the battery life impact of AppleScript widgets. In comparison, persistent command line services that push updates will have no battery life overhead apart from simply keeping BTT open.
Hi, glad you figured it out. What version of BTT are you running? The service runner should automatically start whenever BTT launches and then re-checks every minute. Can you take a screenshot of your Touch Bar configuration in BTT?
Looks like the service runner widget is disabled (third entry Shell Script/Task: that isn’t marked as visible). For automatic service management you should make sure that it’s visible. Did you by chance manually hide that widget, or did it import into BTT 2.6xx that way?
Hey @andrewchidden! Nice preset I've been giving it a try and making a few tweaks here and there to match my dev environment, and so far there's only one thing I'm having problems with: the calendar widget.
What's really strange is that the eventkit-service is running, the web server is set up, the port is correct, everything seems to be fine when I debug, the pid is set properly etc. but the status file stays empty. When I launch it myself from my shell however, with the exact same arguments, it works perfectly and updates the widget in real time.
Any idea why it would work when I run it by myself and not when it's ran by BetterTouchTool calling service-runner.sh ? I can make it so that the script is ran at startup of my computer, since that'd fix the problem, but if I can avoid it that'd be great
Let me know!
EDIT: Actually when I launch the service-runner.sh script in my terminal instead of from BTT, it also works So it seems that the problem comes from running the script from BTT.
System folder changed to another path, since I don't like having too much stuff in my home folder
If I killall, remove the sub directory (or the files) and relaunch BTT, the files are recreated, the pid file is properly set, but the status file is empty.
I since removed it and now my fishrc (equivalent to bashrc) simply calls the service-runner every now and then instead, but at the time of writing my previous message yes it was turned on, visible, the services were running with the expected arguments
I just installed everything a few hours before posting this message so yes, latest versions
Also if you're interested I made a few tweaks I could share on your GH repo, such as:
If the string for the next event is more than X characters long (30 in my case), it's printed as "first 15 characters...last 15 characters" to ensure that it always stays pretty much the same size (important for muscle memory)
Added a few color variants so that if there is a git diff it's highlighted in green while no changes is displayed in plain white; and that if an event is coming up in the next 59 minutes it's highlighted in red (I often forget about events despite the notifications)
Sure, if you make some PRs I can take a look at them. However for the colors, can you put it behind an env variable flag?
Regarding the calendar status file, the only thing I can think of that might be causing it is a lack of calendar access permissions for BTT or similar. Try checking in System preferences (ether security or accessibility, can’t remember).
and I bought a lifetime license. Thanks andrew 
So it seems that the problem comes from running the script from BTT.