I'll definitely add some sort of instruction for the stable release that says the Touch Bar dock mirrors the settings of the actual dock. Will also get Franz in 
EDIT: Done! Will be in the next version.
Another app that might work with the mic toggle is Cisco Jabber:
if application "Cisco Jabber" is running then return input volume of ( get volume settings )
Great, got that in as well 
Also, not sure why but the current beta version (2.563-4) is downloading at 256.4MB!
I would not be surprised if that was the actual uncompressed size of the preset 
this thing has more assets than some standalone apps.
Ummm...Houston, we may a situation here...
Is anyone else noticing tremendous thermal load issues as these new Dock widgets grow? I noticed my fans blowing harder than a politician last night after 2.561-4, but I was running a bunch of processes in the background and didnt think much about it. This morning I loaded 2.563-4 before doing anything else and noticed it was hot again.
Did some very quick testing (far from thorough) but it doesnt appear to be the BTT build but the loads from the script calls that are hammering my processor.
Idle state without BTT running (few background apps and processes running in normal state):
BTT 2.563 with no GC presets running - average temp low 70C after initial load:
As BTT runs and as I select the latter the script iteration, the higer the processor load and temps - up to 96C! 
.
Below I ran GC preset versions from 2.555 up to 2.563-4 and recorded results. I've got to believe the process calls for all the recent badge apps are the source, but interestingly I deselected everything but Messages, Telegram, WhatsApp, and Outlook in 2.563-4 and it made little to no difference:
1 Like
There's definitely something going on, but I don't know what specifically. My system does show the Dock process consuming a lot of energy, but like you said when I disable all the dock widgets it doesn't seem to make a difference.
Argh 
not sure how to fix this. @Andreas_Hegenberg think you could help me with this one? Did I do something stupid with the dock that's causing resource usage to go nuts? Once this bug is fixed I think we can call it stable.
And thank you for such a thorough report @Harrumph!
(Also, only slightly unrelated, but icons still get reset on BTT restart for me. Font color choices also do not persist between copies or imports.)
Updated data points:
-
Deleted all Dock scripts from BTT and restarted. No change in CPU usage; immediate thermal spike
-
Deleted 2.563 - 4 and temps still ran at 95C for a minute plus afterwards before CPU utilization started falling
-
Reinstalled 2.563 -4 via JSON download. Now running at 85C/11% CPU utilization (2.555 at 68C/8%)
-
Disabling visibility of badge scripts did nothing to improve further. Maybe the CPU calls are elsewhere??
Switching to anything 2.555 or prior is an immediate and noticeable performance improvement.
Not sure if this helps, but I think it is related to items relying on System Events. If I switch back to 2.536-5 the system events process doesn't use too much sustained CPU on my machine. If I switch to 2.553-2 System Events becomes the highest sustained CPU usage process. The same also occurs with 2.563-4.
I'll have a look later, maybe something is being executed too often. Unfortunately in many cases it's impossible to tell why some Apple Scripts use a lot of CPU (it depends on the implementation of the specific function you call in the target app). Sometimes this can not be fixed (only by removing problematic Apple Scripts).
Partly performance issues are why the BTT app switcher doesn't show badges
Do you think it would be possible to just call the dock once in a separate widget to get all dock badges, then update the individual app widgets respectively using BTT AppleScript functions? Would that improve performance?
EDIT: So, something like this:
-- Widget UUID list
set FaceTime to "04DD7174-6674-4296-84D0-CA46DAD91871"
set Mail to "04DD7174-6674-4296-84D0-CA46DAD91871"
set Astro to "04DD7174-6674-4296-84D0-CA46DAD91871"
set WhatsApp to "04DD7174-6674-4296-84D0-CA46DAD91871"
tell application "System Events"
tell process "Dock"
try
set appList to value of attribute "AXChildren" of list 1
repeat with x from 1 to number of items in appList
set appName to title of UI element x of list 1
set badgeNumber to value of attribute "AXStatusLabel" of UI element x of list 1
tell application "BetterTouchTool"
try
update_touch_bar_widget appName text badgeNumber
end try
end tell
end repeat
end try
end tell
end tell
But with all the included dock item UUID's. However, when I implemented this test, the dock badge widgets do show up but only with the badge value and no other attributes; for example, tapping this unread mail widget does nothing:
Is there a way to ONLY update the text value and retain all of the other settings? I do feel like such an implementation should be a lot more performant than what I have now, but if it's just a wild goose chase let me know.
It may be slightly more performant but it's hard to tell by how much. Querying the dock is always expensive.
The problem in your script is that update_touch_bar_widget appName text badgeNumber will completely replace the widget's displayed text.
Honestly I think this widget is something I'd need to do natively to make it somehow performant (even then it needs to send the same calls, but at least it can do it directly via the Accessibility API).
How difficult would it be to implement natively? If it were implemented, would it be something like a "get single dock item and badge value" widget? If this is something you think you could add I won't bother refactoring all this and just update it when you add the native implementation
Yes something like that.
I don't know yet whether it will be performant enough, but I'll check. It will however not be in the next release.
But you should definitely remove the current implementation, there are now like 30 or more widgets which run a Apple Script every second, so >= 30 Apple Script calls per second. MacOS just doesn't handle that well enough 
You could leave them in "optionally", activating a few of them won't hurt. Maybe make them run only every few seconds. It's just the massive amount of script calls that causes the CPU spikes.
//edit ah, but I think the current implementation in BTT let's scripts run even if they are not visible (there was some use case for that). So leaving them in you'd need to set the update interval to 0...
Holy crap, it runs scripts even when not visible?! That explains a LOT. Like why disabling them doesn't do anything for performance.
Honestly if you just released an update that did not run scripts that are not visible, I feel like it would make a huge difference - I also feel like that's the expected behavior (I certainly thought so). Many scripts are not visible by default, and my intention was to save on performance while offering additional customization options. And this way I could include these sorts of experimental implementations without crippling peoples' systems, haha.
Will spend some time today fine-tuning the dock script frequencies to see if I can get something that doesn't make my Mac hot enough to stir fry with and make an acceptable default set of enabled badges.
I'm actually not quite sure if they run while hidden - will check that in a minute. Maybe I already changed that a while ago
//edit: ok no, they do not run when not visible. (Tested with do shell script "say \"Run!\"")
1 Like
I'll have a new version with a default dock set shortly. I think I've got things slightly better, gonna fiddle some more... thanks for checking that visibility setting
1 Like
Btw. it looks like these three are real performance killers:
The system events process CPU usage goes up 30% when activating them.
It seems like
tell application "System Events"
set frontmostApp to name of application processes whose frontmost is true
-- return frontmostApp
end tell
is really expensive.
I'm already working on "Application Groups" that can be added to the list of apps in BTT, this will make it possible to have BTT triggers defined for a specific set of apps. However this is still about two weeks away.
For now maybe I can add a function that passes the frontmost app to the apple script, so you could remove that check. I'll look into that.
1 Like
Honestly, I've been considering removing the frontmost app detection part of that script - it's just got so much jankiness that it's more distracting than useful, plus a ridiculous number of apps support refresh. I've been thinking about actually reverting it back to the previous behavior where the refresh button shows up whenever a browser is open instead of just frontmost, and this performance info just sealed the deal for me.
1 Like