Highrez

OK, Its been a few days since I released 2.15 and so far there have been no major bugs reported, bar one possible issue with the new change movement to scroll operation (which I haven't had a chance to look at yet).

However, now is the time to think about the future and what will be in XMBC 2.16 and so, with that in mind, here is my initial list. Note that the red items are the most complex and least likely to get looked at!

The things on my to do list for 2.16 are:

• Add the ability to cancel button chording if the mouse is moved by more than a few pixels
• Investigate change movement to scroll issue
• Fixed missing language template translations
• Add ability to save and load (switch) profiles
• Add ability to disable switching profile on mouse move per profile
• Add ability to cancel chording if the mouse moves
• Fix simulated keystrokes repeating once the button is released
• Fix button chord window text for Run Application
• Fix bug causing mouse speed to default to 0 on a fresh install
• Add ability to distinguish between desktop and other explorer windows
• Fix issue allowing drop-down and spin boxes to be scrolled when disabled
• Add ability to specify a window sub-region to activate window profiles
• Improve the Simulated Keystrokes help panel as discussed in 2.15 Beta, ideally with tag recognition/highlighting of some sort.
• Extend the {PRESS} and {RELEASE} tags to work with a sequence of keys
• Update the installer to use the newly released NSIS 3.0 instead of NSIS 2.x
• Ability to set a different action to click or click and hold (if at all possible)
• Investigate the possibility of detecting more buttons (dont get your hopes up!)

NOTE: Green = Done, Red = Unlikely to be looked at in this beta!

Lets kick things off with 2.16 Beta 1 - coming soon with at least one of the above fixed (the first one).

Regards,
Phil

OK so here is 2.16 Beta 1.

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.15:

• #463 - Added ability to cancel button chording if the mouse cursor moves.

There is no new language template for 2.16 beta 1.

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

Thanks,
Phil

phil wrote:FYI: Ive found already that not being able to drag without waiting 500ms is a real PAIN IN THE ....

Believe me, it's not! The REAL pain in the ... is disabling and re-enabling XMBC every time you need to drag

Happy to see the 2.16 beta thread

ha ha, I should say the same... I found myself doing that sometimes when I was already sick that I have each time remember about that dealy time - tomorrow (today) at work I'll see how it works!


Update:

Wow, amazing, I'm not now only XMBC fan, but Phils's too


Ps, first bag I set delay to 500 ms to last time (in 2.15) check how dragging works. Then I downloaded 2.15.1. I noticed new option (that letting us drag in no time) but the delay time was set to default again, so 750 ms! Probably in other button settings too, I didn't check though.


Next Update:

...and next bug! That new checkbox is working. I mean after I checked it and saved changes then tried how that works all was okey, but when I opened XMBC settings again and went back to that panel with that checkbox it was unchecked . Yes it worked after I checked it first time but then it worked also when it was unchecked. It seems it took to memory checking action but didn't store grafical checking.

I tick the new 'Unblock when the mouse moves' option and hit OK, then I open the chording window again and it is unticked

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

injtsvetkov wrote:I tick the new 'Unblock when the mouse moves' option and hit OK, then I open the chording window again and it is unticked

Yep - same here - odd but I'll sort that out in the next beta!

I don't know how but it worked at my home. Now I'm at work and can't made it working. Probably of that already known bug - it's unticking itself.

Kukurykus wrote:I don't know how but it worked at my home. Now I'm at work and can't made it working. Probably of that already known bug - it's unticking itself.

I suppose you have Win 8.1 at work?

No, win 10 both in work and home.

Mmmm what smells so delicious...
Seems that something yummy's cooking in the oven.
2.16 beta 2 maybe

No... its beer and its not in the oven

cold beer in the winter... that could be dangerous mate, be careful

Well I have found and fixed the bug, 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....

So there will be some delay while I figure this out!

Arghhh!
Thanks,
Phil

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.

For example, I've assigned 'Shift' as the Modifier Key for 'Layer 3' and I'd like to send {CTRL}K using the 'Simulated Keys' command when the 'Middle Button' is clicked (while holding the Shift Layer Modifier Key).
What ends up happening, however, is that the 'Shift' Modifier key also ends up being sent as well (since I'm holding it to activate the layer) - So the window receives Shift+Ctrl+K (instead of just Ctrl+K) - and this totally screws up things...

Is there any way to specify that the 'Layer Modifier Key(s)' do NOT get sent along with the 'Simulated Keys' unless they are explicitly specified? (I tried the {CLEAR} and {RELEASE} tags to no avail).

Thanks in advance for your reply! (and also again many thanks for all the awesome recent work on XMBC!)
-JT

hummm thats 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