GoldenChaos-BTT Support and Feedback Thread

I remember that @Andreas_Hegenberg was working on a "replace existing preset" option for importing so that users wouldn't have to delete their existing GC-BTT first, but I'm not sure what happened to it.

Good job on the last update!

I'm curious as to how you go the DND sensing to work. Which trigger is setting the variable?

Also craaazyy settings system there. I could learn a few things from it I guess. I'd like to note though that BTT gets very laggy while restoring settings. Maybe needs optimisation?
Suggestion: that restore option is a little... whoa-. Maybe you could merge it all into one single applescript, triggering the seperate additional actions from the script instead of by running each action? Not sure if this'll optimise it any more or not but maybe try it out

It's in the DND button in the Option Menu! Basically instead of the script returning true or false, it sets the variable first and then returns the value of the variable, that way the button itself is powered by the value of the variable (which is a good way to confirm that it works). If you have never pressed the button before, it assumes DND is off. This also means that it doesn't use the system control to determine DND status, but neither does BTT so it's consistent in that way. So, at least for now, you have to invoke DND via the button in GC-BTT for it to work. The next step is to add a persistent listener, but that adds a performance hit so I want to test it first.

After that, I hand-edited each badge to wrap it in an if statement that checks the DND variable (a pain but totally worth it). So, if you have a dock badge enabled, it will check the DND variable first before it decides to display anything. If DND is enabled, it returns empty.

Re: performance, it's about as performant as it can get without crashing the app. When I originally made the preset script it was as one massive AppleScript, and it ended up just freezing BTT. Since there was no way to track the progress, I originally had assumed the app crashed, but it turns out it was just taking a really long time. That's how I came up with the idea for the progress bar in the first place, so that the user would have some visual indication that BTT was actually doing something. It doesn't take any longer with the progress bar, actually!

I don't know if there's a way around actually going through each of the steps to restore settings, but it probably won't ever take any longer to load presets at least.

Ah, thats all cool and all.

I see a hole though, if you set DND from the notification centre it probably won't switch the variable. My method with a persistent listener seems to be working well and doesn't add that much CPU usage, but then again on my preset most of the widgets are segmented out into App/CAgroups which cut CPU usage by a lot.

Currently typing on this site my BTT preset is at 2.5 - 5% cpu at idle. I have various safari widgets running (about three that are listening to the website) and about 9 notification widgets on, +1 for the DND handler. My Control Strip highlighting scripts are also running, there are two of them. Seems okay for me here, the DND handler isn't adding much usage.

2-5% CPU usage - not touching the bar, Running:
3x Safari Widgets (3 more segmented in CAGroups and are not active)
2x ControlStrip widgets
9x Notification Widgets
1x DND handler

I can pretty much say that the persistent DND handler is working fine. It'll probably be safe to try it out. Also, you wouldn't need the DND button to flick the variable, (which can also be a problem if it didn't change the actual DND but changed the variable) and it'll know the DND from the notification centre as well.

Also small tip:
I don't know if this is a placebo or whatever, but writing applescripts like this:

tell application "BetterTouchTool" to do something

seems much faster to run than:

tell application "BetterTouchTool" 
    do something
end tell

Seems to work decently well, I'm relying on these to run my haptics engine. They check wheather BTT's haptic variables are on (using shell defaults read) and also checks a BTT variable (checks if the user has haptics on in settings) before producing a click, and they're pretty fast. You can probably tell that I need them to be fast to prevent the clicks from being delayed.

Implemented in the latest experimental version!

1 Like

2 posts were split to a new topic: App-specific Volume Controls

BTT was consuming a lot of energy, I tried to make changes by downloading the latest version and deleting previous presets and somehow I lost most of my configurations of version 2.660 that was working great. However, in Library/Applications Support/BetterTouchTool folder I have the files btt_data_store.version_2_660_build_0968, btt_data_store.version_2_660_build_0968-shm and btt_data_store.version_2_660_build_0968-wal. Can I use them to restore my old configuration?
Thank you!!

These files will be loaded automatically if you start version 2.660

I am using 2.660 now. Do the files btt_data_store.version_2_660_build_0968, btt_data_store.version_2_660_build_0968-shm and btt_data_store.version_2_660_build_0968-wal contain a compilation of all presets I was using at that point? It seems like I could restore only part of the configurations

Yes, they contain all presets :-/
Maybe it was already broken when you were on 2.660?

First of all:
GC-BTT is awesome. Thank you so much!!!

I'm wondering if there is any easy solution to bring back the favicons when you open a new tab?
It's the only feature I'm missing so far because its a feature of Apple Standard Touchbar UI (it's worth to call it like this? :smiley: )
Does anybody have an idea?

This is something I'd love to do. And I think I'm close to being able to. The stuff below is kind of relevant.

Now that I've learned how to use Conditional Activation Groups, I've got a very stupid version of GC-BTT that will switch to the stock Touch Bar only when a text area is in focus, enabling access to autocomplete and autofill. I've found that turning off Apple's Control Strip entirely makes the experience a bit less jarring. I'll refine this behavior and be VERY selective about ever booting out to the stock Touch Bar.

So, to bring things full circle, I plan to use conditional activation groups to basically turn the stock Touch Bar into a modal widget. That way apps with worthwhile Touch Bar controls (so, basically just Safari) will get through without disrupting the overall GC-BTT experience.

EDIT: That release is now live - GoldenChaos-BTT 2.670!

EDIT2: @Andreas_Hegenberg The progress bar visualization for reapplying settings has broken in 2.670 :frowning:

that's probably due to the performance improvements made, some of them prevent unnecessary re-renders. How did you implement the progress bar?

Has anything else broken? (2.670 is quite experimental but should improve performance by up to 50% in many cases)

A lot of visual stuff. The progress bar in this case doesn't even get the chance to show because BTT now more aggressively closes widget groups. So as soon as I click "reapply settings", the group closes.

Additionally, and only tangentially related: For me to refactor some of these features using conditional activation groups, such as the menu bar and dock badges, I need a way to exclude certain activation groups from showing up when any modifier keys are being held. Dock Badges and the Secondary Menu Bar widgets are examples of this; if they show up, the modifier menu layouts break. Is there a way to accomplish this currently?

Hello,

I like this functionality but it can be annoying in some situations. For example. If I have the Notes app open and am working in a Note and have music playing, I am unable to control the music playback using GC-BTT whilst working on my note. I know I could use the system Touch Bar functions for this but it's a bit frustrating.

Unfortunately I can't think of a way around it. I understand why it is working that way but hmmmm.

Interesting feature though!

1 Like

Just uploaded v2.671 alpha, it doesn't restore full functionality of the progress bar, but should make it usable again. On my system reapplying the settings is about 1000% faster with this version.

Unfortunately supporting modifiers in activation groups is kind of complicated because it would mean I need to reevaluate them every time a modifier key is pressed. However it would also be very powerful, so I'll try to integrate that.

It's definitely critical if I'm going to use them, there doesn't seem to be a way around it.

I have a preliminary build where I've refactored the menu bar, dock, and browser tabs widget to all be conditional groups. Behavior seems all over the map currently. Some issues I've noticed:

  • The browser tabs widget shows nothing - I'm not sure why. What am I doing wrong here?
  • The menu bar does not always appear, and inevitably disappears permanently after a little while.
  • In general, rule detection seems to be delayed or spotty. The activation group for detecting the text area for autofill/autocomplete does not reliably fire and, even more critically, does not reliably dismiss itself.
  • A huge part of the menu bar paradigm relies on the ability to have the secondary menu bar set disappear when viewing modifier menus. Without this functionality, I can't really take advantage of the benefits of conditional groups yet.

Here's a build for you to check out and see what I'm talking about, @Andreas_Hegenberg: GoldenChaos-BTT.bttpresetcompressed.bttpresetcompressed (28.2 MB)
(Note to others: Do not download this. The menu bar and dock are totally disconnected from settings, so none of the settings switches work yet.)

After giving it a bit more thought, I think modifier handling will probably always stay trigger-specific. However having a way to set a trigger to only show while not holding some modifier keys should be easy to do.

I'm not sure I understand the current setup. How does the "Browser Tabs" group open? Is there any advantage of putting these into an activation group compared to a normal touch bar group? Is it correct that the current browser tabs group doesn't have any triggers in it?

AX based groups like the auto complete thing can be very complicated and depends very much on the AX support of the app. However your setup seems to work fine here and seems to trigger like intended (only tested with Textedit).

I'm going to sleep now, I'll continue tomorrow!

1 Like

I suppose there isn't much benefit to making browser tabs a conditional group, I just wanted to see what the system was capable of. The browser tabs widget group was indeed empty, but intended to populate with the contents of the browser tabs conditional group. Eventually I was thinking I could turn this into an object system of reusable components, with the widget groups just acting as dumb containers, but that doesn't seem to be the intention here. So I'll move it back to a regular group.

Making the additional modifier setting trigger-specific would still solve my problem, so I'm all for that!