How many gestures do you have configured in the browsers?
Also, what are the names of the browser gesture plug-ins?
The reason I'm asking is because you can relay a gesture. Someone in the original S+ had the same situation with Firegestures (I think that was the name).
Basically, they created the actions for Firefox (in S+, so the action definitions matched the ones in Firegestures) and relayed the gesture.
For example, you have an L gesture in the browser, you make a Firefox app and action which has L as the gesture and for the script:
Code:sp.RelayGesture(action.GesturePoints, action.StrokeButton);
So S+.net is still capturing the gesture, but it just relays (replays) it so the browser plug-in receives it. So that is an option.
The problem with adding a key to disable ignore is not that it's extremely difficult to do, it's that it would introduce some very confusing conditions and complicated logic resulting in state management issues and gesture/action determination uncertainty.
For example:
- You have a global action with a Control modifier and L gesture
- You have another global action with no modifier, but uses the L gesture as well
- Let's say this feature to temporarily disable ignore used the Control key in this example
- So you're in Firefox and press the Control key to allow S+ to capture the mouse and draw an L
- S+ knows that you're holding the Control key to allow the gesture in Firefox, but it cannot know if you want the Control key as a modifier or not, so it would always fire the Control+L action....unless you made the action Capture Modifiers as After. But even then, you could have another global action which had Control+L and Before or Either for Capture Modifiers, and that one would win every time.
This gets more complicated with the Disable S+ if this App Gains Focus checkbox for an ignored application, if the app already gained focus, S+ is disabled and won't capture the mouse, so it can't watch for the Control key. If it wasn't the foreground window, but you drew a gesture over the window, the logic would also need to check the Control key to not ignore it, but in separate code (when foreground window changes), that code would then disable S+.
S+ is already complex and, I'm sure to some, confusing enough as it is; adding yet another layer of complexity only exacerbates this. Plus, the above example with the modifiers is not deterministic...at least not without adding a whole new set of specific logic under this specific scenario. It essentially would result in multiple separate decision trees in multiple places of code that would be difficult to maintain and even more difficult to represent within the user interface. Or only allow temporary ignore disable keys which cannot be modifiers, but that would not likely be very ideal for a whole separate list of reasons.
These reasons are why I'm trying to find an alternative solution, as I honestly do not want to create a feature which can have confusing results or become too complicated for the average user to understand.
Edited by user Sunday, September 1, 2019 12:50:38 PM(UTC)
| Reason: Not specified