XMBC 2.16 Beta

x64 Replacement/Alternative to Microsoft's IntelliMouse application.
Forum rules
Please read the forum rules before posting for the first time.
The more information you can provide, the quicker and more accurately someone can help.
NOTE: To reduce spam, new users can not post links, files or images until they have at least 4 posts.
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: XMBC 2.16 Beta

Post by phil »

JTB3 wrote:In real time, XMBX monitors the active modifier keys and their combinatorial states (expanding on what it does already for hooking the complete mouse).
Realtime is difficult in user land... To do proper real time you need to be in a kernel driver.... but I'll assume thats what you mean otherwise its a no go in XMBC
JTB3 wrote:If a valid modifier/combo is being pressed XMBC simply listens for the next key/mouse action. For each non-modifier 'key' that is additionally pressed, XMBC sends the modifier keys + the non-modifier key. Only If a re-mapped mouse wheel/button is pressed are the modifier keys not sent (unless specified as a sim key(s).
Not possible... When a physicaly key is pressed down, the hook can choose to ignore it or not ignore it. It can not add keys at this time. If it ignores it, it will have to inject another key, so it would have to ignore all keys and re-inject them, because injecting another key would not actually get sent until after the non-modifier is sent. This will introduce lag, no question about it, and some programs that block injected keys would potentially not see any keys at all.
JTB3 wrote:
injtsvetkov wrote:So the idea is to implement a new type of a modifier key with a timer to count how long it has been held down. That way the layer won't be changed at the 'key pressed' message, but if the key is released within a specified period e.g. 100 ms. If the key is released after 100 ms XMBC will do nothing. That way Shift, Ctrl, etc. could be used normally without switching the layer every time you use them for other purpose, you just have to adjust the timer to suit you best. This could be a decent workaround for people like JT who need to use Layer modifier keys in combination with other modifiers.
While I can appreciate this workaround idea, I can also sense problematic edge cases where unexpected behaviors (and frustration) would occur.

What may be a key factor in implementing this is the speed in which keyboard hooks can be switched on/off (as the profiles get de/activated with window changes) How feasible/practical is it to quickly hook and unhook keyboard as a whole?
This might work (and be better than the current timers at time moment... The hook will not get set/reset, the hook would simply set a timer when a modifier key is pressed. If the modifier key is released before the timer fires, or another key is pressed then the timer will be cancelled and nothing will happen. Only once the timer fires will the layer be switched. There are high accuracy timers I can use which would be as close to realtime as you cant get in user land. It may not be 100% perfect but its going to be better than anything else. And of course, I think I can ignore injected keys for modifiers, which means simulated keystrokes, or autohotkey sent keystrokes would not trigger layer modifiers.
JTB3 wrote:Thanks for considering this - and I know it's not trivial to code up - but it sure would add super-useful functionality to the XMBC experience. If it's too time-consuming to implement at this time, perhaps simply putting a 'warning message' on the layer tabs stating "Note; Any associated layer Modifier keys are also included with remapped button/wheel commands." This would have saved me a lot of time & frustration over the years! :)
[/quote][/quote]I could put something on the layer modifier key tab, but I'd rather not have it on the actual layer tab itself to reduce clutter?
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: XMBC 2.16 Beta

Post by phil »

phil wrote:... but my code signing certificate has expired, and while I have bought a new one, I cant install it - I think because certum.pl (my provider) now require a secure cryptographic key (which I dont have) yay....
Update: Certum have eventually confirmed that I need a new smart card and smart card reader to use their certs now. So I need to buy one of them and get it sent from Poland I guess.... So I hope I will be able to release the next beta soon but there will be some delay (and hopefully not too much cost!).

Thanks,
Phil
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
User avatar
JTB3
Dedicated
Posts: 62
Joined: Thu Aug 04, 2016 1:52 am

Re: XMBC 2.16 Beta

Post by JTB3 »

phil wrote:Realtime is difficult in user land... To do proper real time you need to be in a kernel driver.... but I'll assume thats what you mean otherwise its a no go in XMBC
I really meant to say 'good enough' time or 'perceived real-time'. I'd like to think that hooking+re-injecting keystrokes shouldn't introduce any more lag that what we currently experience with the XMBX mouse-button/wheel remappings (I don't personally notice any perceptible mouse lag). Users are not turbo-typing when they are holding down modifier keys - mouse-wheel remappings potentially fire at a much higher rate then keystrokes.
phil wrote:Not possible... When a physicaly key is pressed down, the hook can choose to ignore it or not ignore it. It can not add keys at this time. If it ignores it, it will have to inject another key, so it would have to ignore all keys and re-inject them, because injecting another key would not actually get sent until after the non-modifier is sent. This will introduce lag, no question about it, and some programs that block injected keys would potentially not see any keys at all.
Not sure if you really mean not possible/or practical due to the "ignoring all keys and re-injecting them". This is what XMBS already does with mouse buttons & wheel moves. I wouldn't think the lag would be significantly noticeable. Also, the issue of handling a program/window that doesn't process injected keys could be handled by checking a profile setting that disables the keyboard re-injections (or, conversely, by requiring one to explicitly select the layer re-injection feature on a per-profile basis).
phil wrote:
injtsvetkov wrote:So the idea is to implement a new type of a modifier key with a timer to count how long it has been held down. That way the layer won't be changed at the 'key pressed' message, but if the key is released within a specified period e.g. 100 ms. If the key is released after 100 ms XMBC will do nothing. That way Shift, Ctrl, etc. could be used normally without switching the layer every time you use them for other purpose, you just have to adjust the timer to suit you best. This could be a decent workaround for people like JT who need to use Layer modifier keys in combination with other modifiers.
This might work (and be better than the current timers at time moment... The hook will not get set/reset, the hook would simply set a timer when a modifier key is pressed. If the modifier key is released before the timer fires, or another key is pressed then the timer will be canceled and nothing will happen. Only once the timer fires will the layer be switched. There are high accuracy timers I can use which would be as close to realtime as you cant get in user land. It may not be 100% perfect but its going to be better than anything else. And of course, I think I can ignore injected keys for modifiers, which means simulated keystrokes, or autohotkey sent keystrokes would not trigger layer modifiers.
While this is an interesting idea, It seems functionally different and wouldn't offer the same capability as the former. Injtsvetkov is suggesting that one would have to press and then release the key within a specified time-out window to change the layer, and then perform a similar sequence to switch it back [perhaps I'm not fully understanding what's being proposed here!]. This might help offer some additional use-case capability, but it certainly wouldn't solve the core issue of having quick, modifier-enabled mouse remappings (minus the modifier keys) - like simulating the tilt wheel by holding the shift key down and moving the wheel - and numerous others...

And, BTW, I've never had an issue (thus far) with XMBC layers being triggered unexpectedly by injected (modifier) keys...

This is all good food for thought and I wish I had deeper developer experience to lend here :) I appreciate all of the thoughtful responses! :idea: (and I hope the new card-reader signature system you've ordered arrives quickly and works great! 8) ) Cheers, -JT
System: Win10 Pro-x64 v1702+v1607, Intel i7-7700K (Z270) + i7-4771 (Z87)
Logitech M570 Wireless (5-Button) Trackball + M705 (5-Button) Marathon Mouse
[Bay Area, California]
User avatar
injtsvetkov
Fanatic
Posts: 293
Joined: Mon Jun 06, 2016 8:51 am

Re: XMBC 2.16 Beta

Post by injtsvetkov »

phil wrote:the hook would simply set a timer when a modifier key is pressed. If the modifier key is released before the timer fires, or another key is pressed then the timer will be cancelled and nothing will happen. Only once the timer fires will the layer be switched.
I'm not sure I understand you right :?. If by 'released before the timer fires' you mean 'before the set time period has elapsed', then this is just the opposite of what I suggested. My idea was to switch the layer if the key is released before the set time period elapses, e.g. if it's set to 100 ms - releasing the key somewhere between 0 and 100 ms would switch the layer, while releasing it after 100 ms (or if another key is pressed, as you mentioned) would do nothing. I'm sorry if I did not express myself clear enough but the idea is still not so clear in my head too :)
JTB3 wrote:While this is an interesting idea, It seems functionally different and wouldn't offer the same capability as the former. Injtsvetkov is suggesting that one would have to press and then release the key within a specified time-out window to change the layer, and then perform a similar sequence to switch it back [perhaps I'm not fully understanding what's being proposed here!]. This might help offer some additional use-case capability, but it certainly wouldn't solve the core issue of having quick, modifier-enabled mouse remappings (minus the modifier keys) - like simulating the tilt wheel by holding the shift key down and moving the wheel - and numerous others...
I think JT has grasped the idea. In short, the difference between current Layer modifiers and my suggestion is:

Current: Press and hold Shift - the layer changes, click desired mouse buttons, Release Shift - layer reverts. Your finger is constantly pressing Shift during the mouse clicks.

My suggestion: Hit Shift - the layer changes, click desired mouse buttons, Hit Shift again - layer reverts. Your finger could be placed on the Shift key during the mouse clicks like in the first scenario but you don't need to keep it constantly pressed, even you can move away your finger for a moment if you like :). And the whole point of this is that you can have any modifier combination you like.

Of course it's functionally different and I don't mean replacing the current Layer modifiers, but simply adding the new one with the timer as a workaround for cases with modifier interference. Of course most probably it won't be possible to use the same modifier key as both types simultaneously but this is just one of the problems and I'm sure there will be more, I just don't have enough knowledge to figure them out but Phil certainly does :!:

I remember discussing this modifier interference before and the conclusion was that it's certainly not a good idea to block the physically pressed key so nothing could be done about it. That's why I thought some discussion could bring up fresh ideas and hopefully lead to implementing a decent workaround :)
HAMA Mirano
Windows 8.1 x64, Intel i5-3230M @ 2.60GHz, 4GB
User avatar
JTB3
Dedicated
Posts: 62
Joined: Thu Aug 04, 2016 1:52 am

Re: XMBC 2.16 Beta

Post by JTB3 »

injtsvetkov wrote:I think JT has grasped the idea. In short, the difference between current Layer modifiers and my suggestion is:

Current: Press and hold Shift - the layer changes, click desired mouse buttons, Release Shift - layer reverts. Your finger is constantly pressing Shift during the mouse clicks.

My suggestion: Hit Shift - the layer changes, click desired mouse buttons, Hit Shift again - layer reverts. Your finger could be placed on the Shift key during the mouse clicks like in the first scenario but you don't need to keep it constantly pressed, even you can move away your finger for a moment if you like :). And the whole point of this is that you can have any modifier combination you like.
Thanks for your idea and clarification injtsvetkov :)

Having Layer 'Toggle' Modifier Keys could be a positive (better-than-nothing) workaround. If implemented, I would potentially restrict them so they can NOT be mapped directly to a modifier key(s) (Ctrl, Shift, Alt, and Win) so people don't get faked out and trigger them by accident - In other words, require an accompanying non-modifier key along with a valid modifier combo (no timer needed). Example: 'Shift+F1' could be assigned to "Toggle Layer 4", but 'Ctrl+Shift' or 'Shift' by itself would NOT be permitted. Also, I'd probably display a brief 'Toast" message (in one of the corners of the screen) indicating that the associated Layer has been 'activated'.

FWIW, I wouldn't toss out the full keyboard hook+intercept proposal just yet. The potential benefits are huge! :!: -JT
System: Win10 Pro-x64 v1702+v1607, Intel i7-7700K (Z270) + i7-4771 (Z87)
Logitech M570 Wireless (5-Button) Trackball + M705 (5-Button) Marathon Mouse
[Bay Area, California]
HurdyGuigui
New User
Posts: 1
Joined: Wed Feb 22, 2017 10:24 am

Re: XMBC 2.16 Beta

Post by HurdyGuigui »

Hello,

I am new with X-mouse, and I came across the same problem, triying to change how the ctrl+mousewheel behave in Cubase.

Basically when I am doing ctrl+mousewheelup, I want cubase to press G key. I setup this on layer 2 with ctrl modifier, but problem is Ctrl-G is given to cubase.

I thought that the {CLEAR} command would do the trick in that case, but it didn't.
And isn't the solution of your problem also in this {CLEAR}? Or I don't get it exactly.

Best,

Guilhem
User avatar
injtsvetkov
Fanatic
Posts: 293
Joined: Mon Jun 06, 2016 8:51 am

Re: XMBC 2.16 Beta

Post by injtsvetkov »

This is strange:
Untitled.jpg
Untitled1.jpg
If I set it to another function it displays it normally, but if it's set to 'Run Application: [.....]' it shows 'Button Chording: Button Chording:' instead of 'Button Chording: Run Application: [.....]'. Most probably it's been present since an older version but I finally caught it :P
You do not have the required permissions to view the files attached to this post.
HAMA Mirano
Windows 8.1 x64, Intel i5-3230M @ 2.60GHz, 4GB
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: XMBC 2.16 Beta

Post by phil »

If I set it to another function it displays it normally, but if it's set to 'Run Application: [.....]' it shows 'Button Chording: Button Chording:' instead of 'Button Chording: Run Application: [.....]'. Most probably it's been present since an older version but I finally caught it :P
Yep, its been there since chording was introduced.
It will be fixed in 2.16 beta 2 (which I hope I will be able to release soon as I should get my signing certificate today or tomorrow).

Thanks,
Phil
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: XMBC 2.16 Beta

Post by phil »

OK so here is 2.16 Beta 2 - I finally got my code signing certificate :D.

If you have check for beta versions enabled, you should get notified of a new version and prompted to update in the next day or so. This is the most efficient method (bandwidth wise) as the updates are only a fraction of the size of the full install. Otherwise, you can get the full installation beta HERE. Note that this link will always get you the latest beta version!

Changes since v2.16 Beta 1:
  • #470 - Chorded drop-down text incorrect for Run Application.
  • #469 - Add ability to disable profile switching on mouse move on a per profile basis
  • #468 - Fixed tilt when left or right button held down (non-chorded).
  • #466 - Add ability to detect a profile based on the parent/ancestor window.
  • #465 - Key repeat sometimes continues once button is released.
  • #463 - Only cancel button chording when the mouse moves IF a chord has not been applied.
There is a new language template for 2.16 beta 2.

Any problems, PM me a copy of the log file (or post a snippet in a code block here).

Thanks,
Phil
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
User avatar
Kukurykus
Fanatic
Posts: 388
Joined: Sat Jul 02, 2016 1:15 pm

Re: XMBC 2.16 Beta

Post by Kukurykus »

So we are back to test your great tool!

Ps. I had to download XMBC and install it to have new verstion as checking for updates didn't give expected result this time.

Yuuuuuupi :!: :cheers:

"Unblock when the mouse moves" works! I was so tired without this option, hardly could live waiting delay passed.

Now when I click on something and move it very fast it reacts in no time! No problem to move some window to other location on my display with risk it'll stay in original position if I'll be too fast. Thank You Phil!
HAMA Roma, Rapoo 3920P
Windows 10 x64, Intel i5-4670K @ 3.40GHz, 8GB,
Intel(R) HD Graphics 4600, Intel SSD 179 GB HDD
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: XMBC 2.16 Beta

Post by phil »

Kukurykus wrote: Ps. I had to download XMBC and install it to have new verstion as checking for updates didn't give expected result this time.
Maybe because:
phil wrote: If you have check for beta versions enabled, you should get notified of a new version and prompted to update in the next day or so.
What didn't work about it?
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
User avatar
Kukurykus
Fanatic
Posts: 388
Joined: Sat Jul 02, 2016 1:15 pm

Re: XMBC 2.16 Beta

Post by Kukurykus »

Both regular and beta boxes were checked, like always. But neither I was informed of new beta version after I restarted computer nor it said there is new version when I clicked it to check for updates in tray.
HAMA Roma, Rapoo 3920P
Windows 10 x64, Intel i5-4670K @ 3.40GHz, 8GB,
Intel(R) HD Graphics 4600, Intel SSD 179 GB HDD
User avatar
BriHecato
Dedicated
Posts: 87
Joined: Tue Sep 06, 2016 9:09 am

Re: XMBC 2.16 Beta

Post by BriHecato »

Lately I came across a little need in XMBC (apart of MOAR BUTTONS! of course :P )

Possibility to change whole "settings profile" - rightclick on icon in tray and hover over "load settings" then choose from "Bri profile", "kukurykus profile", "phil profile". Without reloging in windows, without manually replacing xml file in roaming directory.
Let the PC do the hard work = AHK + C# + HTML/CSS/JS + XMBC + Clavier+ + AutoLisp + VBA/OOB
User avatar
Kukurykus
Fanatic
Posts: 388
Joined: Sat Jul 02, 2016 1:15 pm

Re: XMBC 2.16 Beta

Post by Kukurykus »

I noticed such thing (long time ago):

For example I set 5 button as choring (it may be any other button)
Then I set for ScrollUp simulated keystrokes: {MXADD:0}{MYADD:-39}
and for ScrollDown wthis simulated keystrokes: {MXADD:0}{MYADD:39}

(pixels amount is no matter - that was set for my needs, so it can be 1 or any other number of px)

So when I hold 5th button and then I scroll up it takes me up every 39 px for each roll move.
It's the same when I scroll down. Of course it moves a cursor down every 39 pixels.

What is the problem?

When I hold 5th button and scroll up, but for whatever reason I want to change direction, so scroll down.
If I want to do it I have to release 5th button and then press and hold it again to scroll in the other direction.

I think it would be much better if I could change dirrection of cursor moving (so scrolling) without releasing 5th button to press and hold it again.
HAMA Roma, Rapoo 3920P
Windows 10 x64, Intel i5-4670K @ 3.40GHz, 8GB,
Intel(R) HD Graphics 4600, Intel SSD 179 GB HDD
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: XMBC 2.16 Beta

Post by phil »

BriHecato wrote:Lately I came across a little need in XMBC (apart of MOAR BUTTONS! of course :P )

Possibility to change whole "settings profile" - rightclick on icon in tray and hover over "load settings" then choose from "Bri profile", "kukurykus profile", "phil profile". Without reloging in windows, without manually replacing xml file in roaming directory.
Well that's much more likely than more buttons :) I'll see what I can do....
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
Locked