Some apps on Mac will not quit but minimize in the dock and I really don't like it since it clusters my dock. So I set up an action to perform CMD + Q.
The problem I'm having is that sometimes an app is in the background, but the window focus is still on the front window. As a result, when I leftclick x on the background app, the action performed CMD + Q will be applied to the front window instead.
Is there a way to fix this?
you can use the "active/bring to front window under cursor" action before sending the cmd+q
Thanks man. That works like a charm, and can't believe I never found it. I found two additional issues:
Is there any way the BTT could detect whether this is the last opened window or not? For example, if I have two PDFs open in Preview. If I click x on any of them, both windows will be closed since CMD + Q is performed. Is there a way to let BTT perform a CMD + W to close the current window if it is not the last window, but CMD + Q to quit Preview if there is only one window left?
The trigger I set up is not a global one, if I click x on a background app window not in Activation Group, but the front window is an app in the Activation Group, it will trigger the action and perform a CMD + Q on the background window that is not in the Activation Group. For example, the Safari is not in the Activation Group, but the Preview is in the Activation Group. This is what happened:
I also tried "Quit App under Cursor" and it behaves the same. Since Safari is not in the Activation Group, it should minimize to the Dock by the default, but it got quit since Preview in front. Is this a bug or am I missing something? (I've also tried to add a "active/bring to front window under cursor" action first, but the problem persists)
1.) some users here on the forum have attempted this with Apple Script, but I don't believe there is a 100% reliable solution ( Red Button of the last window quits the Application - Setup/Preset Sharing - BetterTouchTool Community (folivora.ai) )
2.) If I understand correctly that's expected behavior. Maybe you could workaround it by using advanced trigger conditions (using the hovered_element_details variable)
But if I use "active/bring to front window under cursor" first, BTT should bring the window to the front and read that window to check if it is in the activation group or not to trigger an action. Right now, this is not the case:
no, that's not how BTT works. After an action sequence is triggered the initial conditions can't matter anymore, otherwise all sort of stuff would break. Imagine action sequences that start in one app but junp through other apps.
You could put your "Quit App Under Cursor" action into a named trigger, and execute that in your action sequence. Named triggers can be put into specific groups that will be determined at the time of the execution of the named trigger.
If this is the case, then what's the purpose of Activate/Bring to Front Window Under Cursor? I believe the current behavior is not consistent at least. If I have two apps and both of them in the Activation Group, this actually does work as intended. The background window will become front window first and then got quit. I think the solution might be to add a condition if front window name is.... or add an action Quit App in Front Window?
Every action in BTT behaves like that, I don't see an inconsistency here.
However if you use the "Quit App Under Cursor" action there is no need to use the "Activate/Bring To Front" action, it's already built-in there.
I think the workaround with the named trigger should work for your use-case though.
I see. Thanks man. However, I didn't find the doc to be very helpful, and it seems like explaining nothing at all. Is there a more detailed instruction to walk me through the setting up process?
Basically you just need to add a named trigger in the "Automations, Named & Other Triggers" section to the activation group you want it to be in. Then assign the "Quit App Under Cursor" action to that named trigger.
Now instead of calling "Quit App Under Cursor" in your action sequence directly, use the "Trigger Named Trigger" action to execute the named trigger you defined.
How did this named trigger different if you just put it in action sequence? Am I missing something here since it behaves the same as before? This is very dangerous since quitting apps unexpectedly can cause data loss, which already happen to me a few times.
Ah sorry, I wasn't clear. You would trigger cmd+q in that named trigger and the trigger that calls the named trigger should first active the window using the "Activate/Bring To Front" action.
That way BTT should first activate the window, then evaluate the conditions when calling the named trigger.
I'm not completely sure whether that will work, but it's the only thing I can think of. If that doesn't work, you can't do it with BTT actions. I think it would still be possible to do with Apple Script.
It looks good to me. Still not working as expected?
Unfortunately, it still behaves the same as before. This could be a really good feature to have. At this moment, I have disabled this trigger since data loss is a bigger issue than convenience.
I use this preset for a while now and it is quite reliable 
@sl-btt feel free to try it out. It does some things that you ask for.
You have to setup which apps you want to close, when there is only one window left though.
