XMBC 2.16 Beta

[afdsadf]

With version 2.15 and this beta, change movement to scroll has been moving the cursor very slightly. Also, when you scroll in a direction and change directions without releasing the button, it moves slightly in the original direction before going in the new one.

If this isn't the right thread to report bugs in I'll be happy to move this somewhere else. Thanks

[phil]

It is the right place to report bugs, but that is not a bug but intentional, because without any movement, it does not work on all device (which was a problem prior to 2.15). And the problem with this is?

[ChowGuy]

phil wrote:it needs to be a small number... 5 seems to work really well, and if I don't need to offer a choice, its much easier. 2.16 beta 1 is now out with this fix only so we can play around and see if it works as it is .

I presume that because of the different user resolutions and mouse speeds/sensitivity it will be necessary to offer the choice, at least in a narrow range (e.g. from 1 to 10). But for testing purposes we can use it as it is now

Just a thought: could you use the DoubleClickWidth setting in the registry (HKCU>ControlPanel>Mouse)? It seemslikew a consistant usage.

[JTB3]

hummm that's an interesting one... Right now, I can see how that could be a problem, but some people actually make use of this problem, so if I change it it may break other things, hummmm....

I will think on it for now and see if anyone else has any comments.
Actually, if someone wanted this to happen, they could use the {layer} commands in sim keys, so on reflection, its probably safe to ignore if I can

Thanks for your reply and openness, Phil. This issue has been pestering me countless times for over 10 yrs (and yes, I'm one of your founding XMBC users! - and sorry for not posting this sooner). Unless the app window can tolerate the layer key(s) being included along with the Sim Keys (and so many can't), the key sequence fails miserably. I've had to abort numerous potentially awesome automation opportunities (and wasted quite a few hours trying to fudge things to work around the issue) because of this.

To make a potential fix/change backward compatible, perhaps a checkbox could be included (placed right near the 'Block original mouse input' box) that says something like 'Don't include (unspecified) Layer Modifier Key(s)' - with the default setting 'unchecked'. This way no existing user profile would be faked out/broken.

Could you also explain about what you mean by 'if someone wanted this to happen, they could use the {layer} commands in sim keys'? Are you just exploring the solution space? If so, I concur, and that would work perfectly with the above checkbox idea! -JT

[JTB3]

Hi Phil,
Not sure if this is a 'Beta' feature request/fix or if there already exists a workaround for this issue:
My issue is that the 'Layer Modifier Keys' are interfering with the 'Simulated Keys' that I'm attempting to send to an application window.

Hi Again Phil,
As I look deeper into this issue, the Layer Modifier Keys themselves are not only getting interspersed with the 'Simulated Keystrokes', they are ALSO being interspersed with ALL of the drop-down functions! This further explains why so many of my desired remappings fail to function.

Let me give you a clear common example of how this inconsistency creates dysfunction - and then propose a solution (which could also work for the 'Simulated Keys' issue I previously raised at the same time).

Example (background): Many mice don't come with the tilt-wheel capability for horizontal scrolling. So a number of applications have helpfully provided this capability by interpreting Shift+Wheel Up/Down to perform horizontal scrolling (Adobe Acrobat, Paint.net, SublimeText, etc. - just to name a few apps). THIS IS AWESOME for those of us using mice/trackballs without a tilt-wheel.

Example (use case): To achieve a similar functionality in apps (like Microsoft Word or Excell) that DON'T provide built-in horizontal scrolling for Shift+WheelUp/Down, I'd like (with the help of XMBC) to be able to, in my default (or specific app) profile, remap the Shift(Layer Modifier Key)+ Wheel Up/Down keys so they send the 'MouseWheel Tilt Left/Right' command to desired app windows.

In XMBC, If I specify the two required remappings (Wheel Up/Down --> Mouse Wheel Tilt Left/Right) in a layer associated with the 'Shift' layer modifier key, these remappings FAIL to achieve the desired result - because the 'Shift' Layer Modifier is being sent along with the Tilt Left/Right commands! Thus negating this capability, along with multitudes of other potentially useful remapping possibilities!

It's hard to believe that more people haven't complained about this irregular/limiting behaviour. I'm guessing that many, until now, may not have experienced this issue because, most of the time, mouse button/wheel remappings are specified in LAYER 1 - which typically does NOT have a modifier key(s) associated with it.

So, I've confirmed and tested that the mouse button/wheel remappings all work great/just as expected in Layer 1 with no associated modifier key - and typically fail miserably in other Layers that have modifier keys (e.g. MS Word and other apps will perfectly interpret the remapped 'Wheel Up/Down --> Mouse Wheel Tilt Left/Right' in Layer 1, BUT NOT IN a Layer with an associated 'Shift', 'Alt' ' or 'CTRL' Modifier Key. XMBC is shooting itself in the foot in these cases!

POTENTIAL SOLUTION/FIX (Backward Compatible): Place a checkbox at the bottom of each Profile/Layer Tab that says something like 'Don't Send Layer Modifier Key(s) with remapped commands' - with the default setting 'unchecked'. This way no existing user profiles would be broken when implemented, and this would also apply to/fix the related 'Simulated Keystrokes' issue.

Sorry for this long post! I tried to give as much background and detail as I could. It would be SOOOO AWESOME and ENABLING if XMBC button/wheel remappings worked consistently across ALL layers with modifiers! I'd be happy to thoroughly help review/test any solutions you come up with. Penny for your thoughts/reactions. Phil... -JT

[phil]

Oh right, now II understand. The problem is, that to do this, I need to block keys and that's going to cause problems - not least, being very annoying if shift (or others) is blocked and does not work as expected. For starters, how do I know you are pressing shift to modify the layers as apposed to writing an upper case character. Second, blocking means then having to inject the key at a later time - and some programs (games) don't accept injected keys which could render the key completely useless. Also, some programs that use direct input and then the keys cant be blocked in a hook.

You're not the first to mention this, I didn't relate your earlier question to this, I thought that your simulated keys were triggering layers - that's a little easier to do something about because you can tell if a key was injected vs a physical (hardware) key being pressed.

To block keys used in layer modifiers is something completely different and far more difficult to accomplish reliably. Having said that, I could use similar techniques to button chording - but trying to predict what your going to do ahead of time is impossible - so its going to introduce lag/unwanted behaviors.

[JTB3]

Oh right, now I understand. The problem is, that to do this, I need to block keys and that's going to cause problems - not least, being very annoying if shift (or others) is blocked and does not work as expected. For starters, how do I know you are pressing shift to modify the layers as opposed to writing an upper case character. Second, blocking means then having to inject the key at a later time - and some programs (games) don't accept injected keys which could render the key completely useless. Also, some programs that use direct input and then the keys cant be blocked in a hook.

You're not the first to mention this, I didn't relate your earlier question to this, I thought that your simulated keys were triggering layers - that's a little easier to do something about because you can tell if a key was injected vs a physical (hardware) key being pressed.

To block keys used in layer modifiers is something completely different and far more difficult to accomplish reliably. Having said that, I could use similar techniques to button chording - but trying to predict what your going to do ahead of time is impossible - so its going to introduce lag/unwanted behaviors.

Thanks for your reply, Phil.
I can totally appreciate that this is a challenging problem to solve - but it's certainly a worthwhile one. By potentially providing a checkbox option on each profile/layer you would not have to worry about a one-approach solution that will work in all situations or for all apps. Modifier keyboard keys would only need to be hooked/intercepted/blocked at the moment a mouse button/wheel is pressed/moved (which typically does not happen when someone is typing text).

There are a huge number of (non-gaming) use cases that would benefit from this feature! If would be great to really unlock this latent potential in XMBC! Really hope you can take on this challenge - It would breathe fresh life into this kick-ass app!

[phil]

An interesting idea (to only look to see if a layer modifier key is down when the mouse button/wheel is sent) but I think there is a problem with that because AFAIK, the only way a key press can be blocked is in a keyboard hook, as it does now. It cant wait until a mouse button is pressed and then decide to go back and block the key so the key will still be held down.

[injtsvetkov]

Seems that the only way to achieve such thing would be to send e.g. 'Shift released' message at the beginning and then 'Shift pressed' message at the end of each command in a layer with Shift modifier key, while effectively blocking the pressed Shift during the execution of the command. If such thing is achievable then maybe there could be such an option with a tick so XMBC could apply this automatically by detecting the particular modifier key for a given layer

[JTB3]

An interesting idea (to only look to see if a layer modifier key is down when the mouse button/wheel is sent) but I think there is a problem with that because AFAIK, the only way a key press can be blocked is in a keyboard hook, as it does now. It cant wait until a mouse button is pressed and then decide to go back and block the key so the key will still be held down.

Yes, you're correct Phil (I had a brief moment of fantastical thinking!)

You would have to hook and intercept all of the (active) layer modifier keys (does XMBC currently do this anyway? at least the mouse is getting hooked...) and use conditional logic to test if a remapped mouse button/wheel is being moved while modifiers are being pressed. If not remapped, then resend the modifier key as pressed - else, If remapped then send just the remapped command or sym-keys as specified. Sounds easy in theory eh?

I'm currently using several AutoHotkey scripts with no conflicts that hook and remap all kinds of hotkey sequences with dozens of specific window configurations. Perhaps the answer lies in deactivating the modifier hooks only if requested by an app-specific profile (e.g. for a particular game window that is sensitive to keyboard hooks).

Really hope you can crack this! I've already got a dozen (or two) pent-up remappings I'd love to implement! -JT

[phil]

Yes XMBC uses a keyboard hook to look for the layer modifier keys, and while the key is down, the layer is switched. The problem is, delaying a key (by delaying I mean blocking and then re-simulating after some time has passed and I can be sure that your not modifying the layer) until it knows if a mouse button is also pressed is going to, at best introduce keyboard lag and at worse, not work at all (as I said before).

How long should it wait, if its more than 100ms then your going to notice, because SHIFT+a letter is not going to work (for example). Should it give up waiting when another (non-modifier) key is pressed (probably), and also when the key is released.... I know its going to be messy after the experiences with button chording... Of course, I know what pitfalls to look out for too so it might not be so bad the second time round..... My main worry is that messing about the the keyboard like that is going to cause arguments when things stop working .

So no promises... Event more so as I'm changing jobs next month and therefore may get less spare time on XMBC - there is a possibility that I may have to stop working on it completely, at least in the short term - of course there is also a possibility that I may get more time to spend on it - I just don't know at this stage!

[injtsvetkov]

Congratulations Phil Good luck with your new job, I wish you to find what you are looking for

In theory there is another possible option but I don't know whether it could be practically achieved. As I think of it, keys like Shift and Ctrl are almost always used in combinations with other keys, which suggests that they are held down for and extended period compared to other (common) keys. And since the use of a Layer modifier key involves holding it down until you click the desired mouse button/s, then I presume it won't be a problem to hit it once (to switch to the other layer) then click the desired mouse button/s and hit it again to go back to the previous layer. 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.

[phil]

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.

But you can already do that with global hotkeys can you not? Just set the revert timer on the layer.

[JTB3]

Yes XMBC uses a keyboard hook to look for the layer modifier keys, and while the key is down, the layer is switched. The problem is, delaying a key (by delaying I mean blocking and then re-simulating after some time has passed and I can be sure that your not modifying the layer) until it knows if a mouse button is also pressed is going to, at best introduce keyboard lag and at worse, not work at all (as I said before).

How long should it wait...

Thx for your response Phil, and congrat's on your new job change!

The ideal solution IMHO would have zero perceivable 'lag' and would require, for each requesting profile (most), that XMBC hooks and intercepts All keyboard keys and mouse wheel/buttons. In real time, XMBX monitors the active modifier keys and their combinatorial states (expanding on what it does already for hooking the complete mouse). 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).

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?

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!

[injtsvetkov]

But you can already do that with global hotkeys can you not? Just set the revert timer on the layer.

Yes, of course! I've also thought of that but there are certain scenarios when it wouldn't be appropriate to use the revert timer (and I suppose that's when people have to use Layer modifiers) because it restricts you to the exact period of reverting to the previous layer and if you need a different period each time you use that Layer modifier you end up with either less time than you need to complete the desired task or with more time than you need and you are forced to wait.
I have found my workaround by putting {Layer:n} command in the end of each Sim Key sequence in the 'secondary' layer and using a global hotkey to trigger it works great in my case. But my 'primary' layer is always Layer 1 and I always use only one MB click in the 'secondary' layer which is an isolated case
Considering that people may use Layer modifiers with different 'primary' layers and do more than one MB clicks (especially if each time the clicking sequence is different) while in the 'secondary' layer, makes me think that implementing such feature (Layer modifier with timer) would generally resolve that 'modifier combination' problem. Of course again we end up with the argument of how many people would actually benefit of this (probably to few ), so maybe this whole discussion is pointless.
Actually I now tried to assign the same hotkey (F1) for 'Layer 2' and for 'Previous Layer' hoping to achieve this:
1 - hit F1 --> switch to Layer 2
2 - hit F1 again --> switch to 'Previous Layer'
which I think could be some workaround in JT's case if he assigns Shift to both. But unfortunately the first hit switched to Layer 2 and the second one did nothing. If it is possible, in such scenario, XMBC to firstly detect which layer is currently active and if the particular layer (Layer 2 in the current example) is active to execute the second command (switch to previous layer). I know it sounds a bit crazy but IMO sometimes a crazy idea leads to a perfect one