Wednesday, November 16, 2022

xGestures lives on: version 1.9.1

I have just finished a new version of xGestures, available as always at the following link:

There aren't any new features in this build, though there are a number of important fixes. Several of you reported to me that xGestures was crashing every time your macOS Ventura systems woke up from sleeping. That should now be fixed. Technically, this is one of those "how did it ever not crash" bugs so this may fix crashes in earlier versions of macOS too.

I also added a little advanced settings button with a toggle that changes how xGestures filters out mouse events. This setting is specifically there to make xGestures work with SteerMouse.

There's a few other little fixes at well that I won't repeat here since it's in the change log.

edit on November 17: I forgot to notarize xGestures before I released it! 😖 But I've since fixed it and re-uploaded it. Hopefully that didn't give so many of you any issues.

Monday, February 21, 2022

Hark! A new version of xGestures, version 1.9.0

Not wanting it to languish for too long, and also wanting to deal with the many emails I've gotten from users asking about xGestures crashing regularly, I've gone ahead and made a new version.

As always, you can download it here:

As mentioned, there are a few crashes that this version fixes. It also automatically removes the quarantine flag from itself after installation, so hopefully the info in the previous blog post will no longer be necessary. And it's now a universal binary! Well, actually, xGestures is old enough that this is the second time it's become a universal binary. Last time it was PowerPC and Intel. This time it's Intel and Apple Silicon.

But... this version also adds a new feature! This is one that I should have added a long, long time ago. It's a simple check box in the "Options" tab that reads: Bring window to front when using keystroke or menu item actions

It's fairly straight forward: if you perform a gesture that's assigned an action for typing a keystroke or picking a menu item, xGestures will bring whichever window that'll receive the action to the front before executing it. The reason is simple: windows that aren't in the front can't receive keystrokes and apps that aren't frontmost can't have their menus picked.

This is mainly intended to be used with the "Window under the start of the gesture determines the application" feature. Before now, if you performed a gesture over a window that wasn't frontmost, any keystroke xGestures types would go to the wrong window, or even the wrong application! And if the gesture was meant to pick a menu item, it would just flat out fail.

So, if you have "Window under the start of the gesture determines the application" enabled, you totally want to also enable "Bring window to front when using keystroke or menu item actions". It doesn't get turned on by default because I staunchly believe that minor application updates should not cause their behavior to change, and this way no one gets caught off guard. But nonetheless you want that enabled.