| Author |
 Topic  |
|
|
plunt
Italy
88 Posts |
 Posted - 12/25/2012 : 15:47:08
|
| It would be useful to add an action when you click the mouse button without gesture, to be able to handle the mouse with a different program from the operating system. |
|
|
Rob
USA
2615 Posts |
Posted - 12/25/2012 : 18:28:36
|
| A little more details? Also note that with modifiers, a gesture is not required. I have many actions which are defined without a gesture selected, so I want to understand exactly what you're looking for. |
 |
|
|
plunt
Italy
88 Posts |
Posted - 12/26/2012 : 00:23:35
|
I know the action with not gesture work with modifier.
I would to manage right click with other program if not have gesture.
I would, if not have gesture, launch a command to execute code from other program. F.e to minimize the window when right click on minimize button. |
|
|
|
breakcore
Russia
74 Posts |
Posted - 12/26/2012 : 06:51:52
|
I think plunt suggests to have an option to trigger the right/middle button clicks for certain apps without using any modifiers. And I think that's a great idea as there are a lot of program UIs where right/middle click doesn't do anything.
Of cause I may missing something here=) |
|
|
|
plunt
Italy
88 Posts |
Posted - 12/26/2012 : 07:18:28
|
quote:
Originally posted by breakcore
an option to trigger the right/middle button clicks for certain apps without using any modifiers
Yes, is this, ty :) |
|
|
|
Rob
USA
2615 Posts |
Posted - 12/26/2012 : 09:59:01
|
I'll leave this open for now. Right away, I don't think this would easily fit into the code (in addition to adding more overhead for mouse messages, but that's another matter). However, I'll look through the code and think about how it could be added to see if it feels right to add something like it.
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 an 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.
(yes, this is starting to get off-topic!)
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+.
Now, add in the checks for this request, and it becomes a lot messier. Meaning, S+ would handle more than just the stroke button, so middle-clicking in any window would 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 this functionality 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 the mouse wheel relay request, adding a bunch of logic checks there would also become intrusive and cause a performance hit for every single mouse wheel tick.
This is where I have to make tough choices. It's not about this 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.
I know this post went a little off course, 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"
|
|
|
|
plunt
Italy
88 Posts |
Posted - 12/26/2012 : 12:37:54
|
| I understand, and I defer to your assessment. :) |
|
|
|
breakcore
Russia
74 Posts |
Posted - 12/26/2012 : 14:38:49
|
Great and informative post, may be something like that should be sticked at the top of requests forum branch. It's hard to put request and not appear demanding for users without good understanding of how the program works. So if such user appears giving you unreasonable requests you could just redirect him to that post)))
I'm sure all S+ users want this program to keep as responsive as it is now. For me it's also number 1 priority. Thank you!
|
|
|
| |
Topic |
|
|
|
[DEFERRED] No gesture action
Forum Locked
