Page 1 of 3

Implement Mouse Chording

Posted: Sun Jun 12, 2016 4:31 pm
by ziongates
Awesome application. Add An Awesome Enhancement: Mouse Chording
https://en.wikipedia.org/wiki/Mouse_chording
For those that don't know, mouse chording is VERY POWERFUL and Easy to use.
It's simply clicking a mouse button while holding down another mouse button.

This opens many more options.
These would be added as options in the 'Layers' dialog.
It can be implemented 2 ways on a layer
  • Chords only Exclusive Mode (regular single clicks disabled, to avoid click clashes, respond to chords only)
  • Chords and single clicks can be recognized (if you can program XMouse to interpret chords and single clicks simultaneously)
See proposed Layer Config in link below:
https://photos.google.com/u/2/photo/AF1 ... 0aqSbLqMpJ

Hold the left button and click the right button
Hold the left button and click the middle button
Hold the right button and click the left button
Hold the right button and click the middle button
Hold the middle button and click the left button
Hold the middle button and click the right button

PowerPro: A freeware program with mouse chording and functionality like XMouse.
Any mouse button or hotkey can be configured (per window class) to trigger any function.
http://powerpro.cresadu.com/

Re: Implement Mouse Chording

Posted: Mon Jun 13, 2016 9:01 am
by phil
Hi, this one is on the to-do list. It has been there for many years because its an incredibly complicated thing to do reliably - and so far I have been unable to make it work.

The problem is, XMBC uses mouse hooks. Mouse hooks execute at the user level rather than kernel (driver) level and as such the timing can not be considered reliable. Second to that, when buttons are set to "Nothing don't intercept" XMBC just ignored the messages but with chording, XMBC would have to reject every mouse message and simulate them (once it knows if its a chord or not) and as simulated mouse input does not always work (some games and other apps) then that could potentially completely stop the buttons working. All that and the additional complication of the user interface has caused this to be the most delayed feature request simply due to the amount of effort involved and the potentiality of it not working well!

So one day this might happen, but I'm making no promises. For sure, if it does happen, it will likely be a major version change (not that that makes any difference).

I was looking to offer chording on buttons 4 and 5 first as that would be less of a problem with simulation as mentioned above.

Thanks,
Phil

Re: Implement Mouse Chording

Posted: Wed Jun 15, 2016 5:25 am
by ziongates
Complicated, Wow!
I thought it would just be a matter of an 'IF' statement:
if rightclick = true AND leftclick = true then... COMPILE!

In your interface the button sections turn yellow when the corresponding mouse button is pressed, even for multiple buttons simultaneously. So it appears as if your code is capable of doing this easily because you CAN have multiple YELLOW highlights, indicating multiple distinct buttons in the 'pressed state', so xmouse is currently detecting Chording, It should be just a matter of placing the logic to respond to Chording. I think you may be closer than you realize. There has to be a way.
Mouse hooks execute at the user level rather than kernel (driver) level and as such the timing can not be considered reliable.
Also no timing is involved with chording.
The trigger of a chord is the 2nd click (whenever it happens). The 2nd click does not have to happen within say a 500ms window of time, time here is irrelevant. (there are chording types that may have timing involved, I'm not referring to those)

Re: Implement Mouse Chording

Posted: Wed Jun 15, 2016 8:15 pm
by phil
ziongates wrote:Complicated, Wow!
Also no timing is involved with chording.
The trigger of a chord is the 2nd click (whenever it happens). The 2nd click does not have to happen within say a 500ms window of time, time here is irrelevant. (there are chording types that may have timing involved, I'm not referring to those)
But you are forgetting something, XMBC can not let the first button pressed message through until it know or not if there is a second click coming (at any time). So XMBC would have to block the first button down until it knows if or not another button is clicked. And if not (the first button is released) XMBC then would have to simulate the original (blocked) button down - and there lays the biggest problem, as not all applications work with simulated input.

If it was simple, I would have done it years ago!

Re: Implement Mouse Chording

Posted: Tue Jun 21, 2016 4:40 pm
by injtsvetkov
Just a suggestion:

Could it be a work around if XMBC lets the first button pressed message through anyway but still be alert that a second button could be pressed until the first one is not released? It is not ideal but if that is possible than some good functionality could be gained no mater that the first button pressed message is executed.

Please excuse me if I wrote some nonsense.

Re: Implement Mouse Chording

Posted: Tue Jun 21, 2016 7:56 pm
by phil
Yes, but then the chances are you will end up performing 2 actions instead of one. Sp if you did that with the left mouse button, it would register a click on whatever the mouse was over :(

Re: Implement Mouse Chording

Posted: Tue Jun 21, 2016 10:53 pm
by injtsvetkov
Yes, but there are some applications and games which use middle button or right button for changing viewpoint and when you press and hold that button - nothing happens unless you move the mouse. For example SolidWorks uses the middle click for dynamic change of viewpoint and one could easily make chords like: press down middle button and then press LMB, RMB, MB4 or MB5 (in fact when you hold down the middle button over any button on any toolbar nothing happens even if you move the mouse). The way I see it, that is 4 more unique buttons in each layer, which is quite good. The only inconvenience is that if going to use chords, one should first consider whether executing the first button pressed message would do any harm. Even though it's not perfect (because you won't be able to use all possible button combinations on the mouse), it is still a lot better than no chords at all :)

Re: Implement Mouse Chording

Posted: Wed Jun 22, 2016 12:12 am
by phil
True - and that's also why I was considering doing chords with buttons 4 & 5 to start with (ans maybe button 3)

Re: Implement Mouse Chording

Posted: Wed Jun 22, 2016 3:45 am
by ChowGuy
PMJI Phil, and just brainstorming here, not really asking for a feature, but currently when you switch to a layer with a hotkey (including one sent as a simulated key) there is an option to "switch to <layer><n> after" timeout to drop you back out. This doesn't apply to the "switch to layern" function on a mouse click, but I've been playing around with <simulate> {LAYERn}, blocking, and a 1-second timeout to implement chording.

This lets use any of the other actions as the "chorded" button or pass them through unintercepted without passing the original through. The down side of course is that I have to double-click on the first button in order to pass that through but it's a small price to pay, particularly for buttons 3-5.

I've been wondering though if similar sort of timeout out option could be added to the automatic "revert layer" function (or an alternative function) that would allow you to eat the initial click, but revert and regurgitate it if there was no subsequent action. This won't get you around the problem of programs that do like simulated actions, so it's not an ideal solution, but closer then we have now.

Re: Implement Mouse Chording

Posted: Wed Jun 22, 2016 8:58 am
by phil
Brainstorming is good - anything to trigger that light bulb :idea: moment :)
So effectively, you're asking for the layer switch mouse action (which currently is instantaneous, only when the mouse button is held down) to revert after a delay, or even better, after the next button (whatever it may be) is released.... It might work, i'll have a think and see how/if that can be added without too much hassle (otherwise I may just as well try and implement some sort of chording).

Main problem at the moment is finding more than a couple of hours here and there to look at XMBC!

Thanks,
Phil

Re: Implement Mouse Chording

Posted: Sat Jun 25, 2016 9:23 pm
by phil
Well I have been playing around and tinkering with chording...
The good news, is I think I have something that works. Im not convinced how stable/reliable it will be but first impressions are pretty good actually.

So 2.14 Beta 1 looks like it might finally possible to implement chording. The current work flow is as follows...

I've tried to keep it reasonably simple, you just have to select "Button Chording" in the dropdown. That then opens a new window, allowing you to choose the actions for each button when pressed while the chord button is held down.

It seems to work, even for the left button (although I'm still nervous about that and for sure it wont work properly in any programs that block simulated button input.

I'm still working on the beta but I hope to make something available for you to test (PLEASE get involved and help me test it to make sure I havn't broken anything as there were quite a lot of structual changes).

Thanks,
Phil

Re: Implement Mouse Chording

Posted: Fri Jul 01, 2016 9:11 am
by injtsvetkov
Thanks a lot Phil. That was really fast :)

I have already updated to v2.14 Beta 2 and very soon I'll try the chording to a game that blocks simulated keys for sure and I'll post my findings :)

Greetings!
Iliya

Re: Implement Mouse Chording

Posted: Tue Jul 05, 2016 11:20 pm
by injtsvetkov
Looks like Button Chording is working perfectly and is quite simple and intuitive :wink:

Just two things I think need a touch:

- When there already is a setting (lets say a 'Simulated keys') on a button that you want to use for initial button for chording, it would be better when you chose 'Button chording' that setting to be transferred to the 'Default (No Chord)' position so you won't accidentally lose it if you hit 'Apply'. And also if it is possible when you revert back from 'Button chording' the setting of the 'Default (No Chord)' position to be transferred back to the initial button.

- When you set a button to 'Button Chording' you can't see the setting of it (like 'Simulated Keys (pressed)[setting]) and when you set 2 or 3 buttons to chording you get confused which is which. It would be great to see the setting for the 'Default (No Chord)' button like this:
'Button Chording [setting of the 'Default (No Chord)' button]'
or just
'B/C [setting of the 'Default (No Chord)' button]' for simplicity.
This also could be done for the simulated keys:
'S/K (pressed)[setting]'
to avoid the combination:
'Button Chording [Simulated Keys (pressed)[setting]'
which would prevent the user from seeing the actual setting.

I hope my explanations are not too much confusing :?

Greetings!
Iliya

Re: Implement Mouse Chording

Posted: Wed Jul 06, 2016 1:11 am
by ChowGuy
Phil wrote:Yes, but there are some applications and games which use middle button or right button for changing viewpoint and when you press and hold that button - nothing happens unless you move the mouse.
Which so far is about the only problem I see with the current implementation. Ie, if you have "button chording" assigned, the the initial button (or any action assigned as "default") does not get seen until you release it. Admittedly this mostly affects button1 [drag] button2 [mouse gestures] and maybe button3 for some applications, but for those who have only three-button mice to begin that's a major limitation.

That was pretty much the point of my suggesting a drop time in which to detect a second action or abandon the mapping, much like the existing "Double-Click Speed" option.

On the whole though, it's working well, thanks. :D

Re: Implement Mouse Chording

Posted: Wed Jul 06, 2016 8:55 pm
by phil
the drop time thing is a no-go though because I cant let it through and the subsequently drop it, once its through, its through and has to be released (causing what ever that button does to happen as well as anything else.

I think we will just have to live with that limitation!

Phil