One-click worth of delay in executing annotation commands in some Apps

(This report was originally posted on GitHub https://github.com/folivoraAI/BetterTouchTool/issues/2354. I continue to experience the same problem, so in the hope of getting some response, I am reposting it here.)

Description of bug/feature request/question:

There is often a one-click worth of delay in the execution of certain commands to which I have assigned some trackpad gestures.

I use BTT in conjunction with Skim, the PDF reader, and in particular I assign trackpad gestures to certain annotation commands: for example, I have tiptap left (1 finger fix) to underline the selected text, and tiptap middle (2 fingers fix) to draw a box around the selected element, and so on.

For a long while (roughly, I believe since Sierra came out and I started using it), it often happens that, when I try to execute one of these annotation commands by a trackpad gesture assigned through BTT, Skim does not execute it just then, but only at my next click. Since a click after some text is selected cancels that selection, this means that I cannot fail to execute the command (underlining, drawing a box around, etc.) on the selection.

I've not so far been able to figure out exactly what triggers this, but it happens quite often (and makes annotating considerably more cumbersome). When this happens, I either have to call up a contextual menu or select a pull-down menu from the menu bar, and run the mouse pointer over some of its items (without selecting any); this resolves the problem, and I can select a text and annotate it again—at least for another while, when the problem recurs.

I've reported this problem to the Skim developer, who suspects that the issue might be with BTT. And indeed, when I try doing the same things with BTT turned off, that is, when I try to annotate things using the keyboard shortcuts (either default ones or assigned through the System Preference), I do not have this problem. So now I wonder if this is a phenomenon you, Andreas, are aware of, and whether you might be able to fix it, or know some way around.

Sorry for being verbose; I hope my description makes sense. I am, like many others, so reliant on BTT for daily work that small glitches like this can be a big deal. Many thanks in advance!

Affected input device (e.g. MacBook Trackpad, Magic Mouse/Trackpad, Touch Bar, etc.):

Trackpads (both the one built-in a MacBook, and the external one)

Device information:

Type of Mac: MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports),
macOS version: HighSierra 10.13.3 (17D47).
BetterTouchTool version: 2.422 (779)

Additional information (e.g. StackTraces, related issues, screenshots, workarounds, etc.):

Note: Before bug reporting, please make sure you have the latest version of BetterTouchTool and that you have already tried to restart your system :-). If you encounter a crash, please attach a crash log from the macOS Console.app from the "User Diagnostic Reports" section.

How does your Skim setup in BTT look like?
Are you assigning keyboard shortcuts to the gestures?

Maybe Skim is using some non-standard keyboard shortcut handling, in that case maybe try to enable compatibility mode, which causes BTT to send keyboard shortcuts at the lowest possible level:
image

Alternatively try to use the "Trigger Menubar Menuitem" predefined action instead of keyboard shortcuts.

Hi Andreas,

Many thanks for this reply with these suggestions. I attach two screenshots, first my Skim setup before (the compatibility mode is off), and then the setup I now have, after trying out your suggestions (in all combinations).


Some of your suggestions do seem to improve the behaviour. In particular, using gestures to trigger menu items (as opposed to trigger shortcuts), with the compatibility mode off, seems to resolve the issue—smooth responses without the delay I was troubled by.

And yet, alas, it does not resolve the problem completely. I do not know what triggers it, but after working with this configuration for a few minutes, inevitably Skim hangs. When I try to execute a command (e.g. highlighting a text), the cursor, which is a black arrow, becomes a white glove with one finger up, signalling that it's ready to receive the command, but it never executes the command. In fact Skim no longer accepts any command, and I have to force-quit it. Looking at the Activity Monitor, I can see that it does not freeze (Skim does not turn red with 'not responding' sign), but begins eating nearly 100% of CPU.

Would you be able to suggest anything else I might try? I feel we are almost there…

Damn, that's a bug in the Accessibility API handling in Skim then ;-(

I will download the app and see whether I can find a workaround.
Did you also try shortcut compatibility mode or did you switch to menubar commands directly?