Remember that my highest priority is always keeping S+ as efficient as possible. Many requests involve adding more and more checks and code to the mouse hook, which over time would make S+ more and more intrusive to the user experience (noticeable delays when clicking mouse buttons, etc.). Some things can be added which have little to no effect and I don't mind adding as long as it doesn't interfere with the core operation. Although, some would only be used by a few people and cause performance to be reduced for everyone. While a single request won't likely have a measurable impact, they can add up.
It puts me in a difficult position since I hate telling people "no", but I also have to consider the overall long term health and performance of S+. I always want S+ to be as responsive, powerful, and flexible as possible; but I also can't make everyone happy without affecting others' usage negatively.
For example, here's the simplified flow of the mouse hook:IF: This a mouse wheel event and Mouse Wheel Relay is enabled?
THEN: Forward to the event to the control below the cursor
IF: The stroke button has been pressed
THEN:
IF: The window below the mouse is in the Ignored list (PERFORMANCE HIT)
THEN: Pass the mouse event along
ELSE: Start capturing mouse movements and modifiers
IF: The stroke button has been released AND S+ is currently capturing a gesture/action
THEN: Go through all defined applications and look for an app match first (PERF. HIT)
IF: App match
THEN: Go through all actions to see if there's a gesture/modifier match within that app (PERF. HIT)
ELSE: Go through all Global Actions and look for a gesture/modifier match (PERF. HIT)
IF: Match was found
THEN: Execute action
Overall, it's pretty straight-forward and though it has a few performance hits, they're completely necessary to the core functioning of S+.
Start adding in all kinds of additional checks and it becomes a lot messier. For example, having S+ handle more than just the stroke button would cause middle-clicking in any window to require S+ to enumerate all ignored windows, apps, and/or global actions just to check to see if something was defined for that mouse button. Even if it's just the stroke button, right now if you do a simple right-click (press and release), the only performance hit is the initial check on mouse down to see if the window is in the ignored list, so right-clicking in programs is very responsive. Adding the functionality to have an app action fire only for a right-click (no gesture or modifiers) would affect all right-clicks, adding the amount of processing that has to occur (check all apps for a match, then all actions...no match? check all global actions...still no match? ok, then they just wanted to do a basic right-click). Same goes for changes to the mouse wheel relay functionality, adding a bunch of logic checks there would also become intrusive and cause a performance hit for every single mouse wheel tick.
Unfortunately, I have to make tough choices. It's not about one request all by itself, it's when there are 10 requests to add something which impacts the mouse hook callback; S+ would increasingly interfere with normal (non-action/gesture) mouse clicks just to check 10 different things to see if something else should occur instead of what the user wants to do (in this example, just right-click the mouse without having S+ take over for any longer than absolutely necessary).
Also, with the above in mind, I've always believed that other than some hot keys and the optional mouse wheel relay feature, S+ should not do anything until the stroke button is pressed. The user understands that they installed a mouse gesture program which is assigned to a specific button, they accept that things will be a little different when clicking that button. However, they didn't install something which is watching all of the buttons with conditional logic. I feel that's too intrusive and I'd very likely start to hear about all kinds of random conflicts/collisions with other miscellaneous programs/utilities which are also trying to handle those buttons.
I will always try my best to accommodate S+ users and I feel I usually do. But, there are times when I simply have to say "no" for the sake of the bigger picture. Specifically, this mostly relates to requests involving the mouse hook as that is an absolutely performance-critical section of code; requests that relate to functionality after (or completely outside of) the primary logic above you won't see me opposing this strongly since it's within the intended flow and design of the program.
Of course, there are other requests which do not have to do with the mouse hook (like copy and pasting actions) that I never seem to get around to. In these cases, I may feel that it's a feature which, while it may be really convenient every now and then, it's not something which most people are doing every day. Since I only have to much time to work on S+, I am picky about what I add and what I just leave open for a major rewrite or for when I just get in the mood to take care of random things.
This post may sound a little harsh, but something that I wanted to put in writing so people can better understand why I may shoot down certain requests. By no means am I trying to be difficult.  Just trying to make sure that S+ remains efficient, unobtrusive, and easy to maintain for years to come!
"You can please some of the people all of the time, and all of the people some of the time, but you cannot please all of the people all of the time" |
NOTES ABOUT REQUESTS
Forum Locked
Topic Locked
Posted - 12/26/2012 : 15:19:12
