Page 1 of 10

XMBC 2.17 Beta

Posted: Sun Jul 02, 2017 7:05 pm
by phil
OK, Its been a few days since I released 2.16.1 and so far there have been no major issues.

Now is the time to think about the future and what will be in XMBC 2.17 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!

Also note that just because something is on the list, does not guarantee it will get added in 2.17!

The things on my to do list for 2.17 are:
  • #498 - Add ability to execute a default button action when using change movement to scroll and no movement is made (a bit like the default chord action if no chord is made)
  • #504 - Add two new ACTIVATE simkey tags: {ACTIVATEPARENT} and {ACTIVATETOP}
  • #503 - Add the ability for one profile to match multiple processes, captions and window classes
  • #502 - Prevent the installer from launching the browser as an elevated user post install/update - this should also fix the issues where it uses IE instead of your default browser in some cases.
  • #501- Modify the behavior of Simulate Keystrokes so it does not check the current keyboard status of extended keys and always sends the {SHIFT}, {CTRL}, {ALT} (etc.) extended keys
  • #513 - Ability to set a different action to click or click and hold (if at all possible)
  • #500 - Add an action to drag the window under the cursor and an action to size the window under the cursor
  • #496 - Add new simkey sticky repeat for duration method
  • #480 - Investigate adding ability to change windows double click and drag tolerance time
  • #459 - Investigate changing the {PRESS} and {RELEASE} tags
  • #460 - Improve the simulated keystrokes help panel
  • Update the installer to use the newly released NSIS 3.0 instead of NSIS 2.x
  • 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.17 Beta 1 - coming soon with some of the above fixed.

Regards,
Phil

Re: XMBC 2.17 Beta

Posted: Sun Jul 02, 2017 7:11 pm
by phil
OK so here is 2.17 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.16.1:
  • #504 - Added two new activation simkey tags {ACTIVATEPARENT} & {ACTIVATETOP}.
  • #503 - Add ability for window profiles to match on multiple processes, captions, and classes.
  • #502 - Prevent browser launching as admin from the installation/update packages.
  • #501 - Modified behaviour of simkeys so it does not check if the extended key is already down.
  • #498 - Add ability to specify a default button action in Change Movement To Scroll, when no scrolling occurs.
There is a new language template for 2.17 beta 1.

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

Thanks,
Phil

Re: XMBC 2.17 Beta

Posted: Mon Jul 03, 2017 2:53 pm
by maxoku
Great, thanks for adding ability to match on multiple processes and classes, works like suppose to. :D

Don't really know what new activate tags suppose to do, but I've tested them. Activate top seems to work like the regular one with exception that not all elements are being focused and only the window itself is activated. E.g. when I click on edit box it works the same, but if I click on check boxes they're not being focused (living focus on edit box) activating only the window, with the regular tag edit box looses the focus for checkbox. Activate parent works the same like top, but only if I focus on an element (like edit box or checkbox) then the window is activated, but if I click on any other area (like title-bar) then it doesn't activate anything.

Re: XMBC 2.17 Beta

Posted: Mon Jul 03, 2017 3:01 pm
by phil
ACTIVATEPARENT gets the window under the cursor, then gets its parent and uses that.
ACTIVATETOP gets the window under the cursor, then traverses up the window tree to the top (GetAncestor with GA_ROOT)

Then it allies the same logic as {ACTIVATE} does. So basically they are all quite similar but in theory allow you to go up a level or up to the top.
Of course, the {ACTIVATE} logic also has the special cases (where it gets parents of buttons/checkboxes etc anyway)

Re: XMBC 2.17 Beta

Posted: Mon Jul 03, 2017 3:11 pm
by maxoku
Don't know if I got all of that (language problems :P ), but it seems that not everything works like suppose to. Read my description how it worked for me (I hope you understood it) and compare if it is desired behavior. Well that parent tag not activating anything if not clicked on element worries me the most. :?

Re: XMBC 2.17 Beta

Posted: Mon Jul 03, 2017 6:37 pm
by phil
I did read your description (its not all that clear to me - language issues again perhaps!)

The parent tag should activate the parent of whatever is clicked on. Only if its already topmost should it fail (and admittedly then, if there is no parent it should jut use the detected window).

Don't forget, I put a lot of special rules in for activate, so in many cases, it already goes to the parent if it detects certain window types. That maybe why you dont notice a difference. However, there will be cases that I have not yet encountered and coded for where the new tags might be useful. If activate is working 100% of the time, then you simply dont need to use the other two. If activate is not working and the other two also dont work, then that's where we need to discuss it, ideally with clear examples.

Re: XMBC 2.17 Beta

Posted: Mon Jul 03, 2017 7:08 pm
by maxoku
The thing I'm reporting is that the parent tag doesn't work (not activating the window) if I don't click on an element. If I click on title-bar or background (blank space) of the window there's nothing happens. Besides that new tags seem to work properly.

Re: XMBC 2.17 Beta

Posted: Mon Jul 03, 2017 7:27 pm
by phil
OK, that will be because the thing you clicked is probably top level and does not have a parent... Taht would be why nothing activates.. Strictly speaking that is correct behavior but I can understand its not really what we want :)

I will change the code so that if there is no parent, it reverts to the same as {activate} which should resolve that....

Re: XMBC 2.17 Beta

Posted: Tue Jul 04, 2017 3:43 am
by injtsvetkov
Woooow :o

#503 - Add ability for window profiles to match on multiple processes, captions, and classes.

Congratz on that Phil :!:
I think it's HUGE :D

So far I have managed to combine "explorer.exe||explorer.exe (desktop)" in one profile. I had a few unsuccessful attempts but when I left the "Class" and "Parent Class" fields empty it worked like a charm :)

Can you please give us some clarification about this change when you have some time and maybe some examples about how it is supposed to work and what limitations are there (e.g. maximum number of processes in one profile or anything else you can think of).

Here is what happened:
I deactivated (unticked) my "explorer.exe" profile and I tried to change my "explorer.exe (desktop)" profile by adding "||explorer.exe" in the "Profile" field.
After I confirmed it works, I tried to add "||explorer.exe (desktop)" to my "explorer.exe" profile and I got the "You can not add two entries for the same application." message :?
That made me realize that actually I already have 2 profiles containing "explorer.exe" which I suppose is an issue :roll:

About "Ability to set a different action to click or click and hold (if at all possible)" here is what I think:
Like with chording, it should have "Block/Delay" option. When it is enabled, the "pressed" message will be blocked at first and there should be a 'ms' timer so here are the 4 cases which I see:
1 - If the button is released before the set 'ms', send normal "click"
2 - If not released, after the set 'ms' send the custom command and then block the "released" message
3 - If the cursor moves before the set 'ms', send the button "pressed" message so drag would be possible (like the "Unblock when the mouse moves" option in chording)
4 - If the cursor moves before the set 'ms', send the custom command, if no movement, after the set 'ms' - send the button "pressed" message so drag would be possible

But the thing that concerns me more is how this "click and hold" functionality could also be implemented in the "chording" feature coz otherwise, using a button for "click and hold" would mean losing the ability to use that button for chording which IMO is a great limitation! Except if the "click and hold" feature is not limited to just one custom command but it has an option to show a list of commands so we could pick up the desired one by releasing the button on it!

Maybe the option to send custom command after some 'ms' could be added to the chord button. And how about sending custom command if the mouse moves while the chord button is pressed...

Thanks
Iliya

Re: XMBC 2.17 Beta

Posted: Tue Jul 04, 2017 8:06 am
by phil
injtsvetkov wrote: Tue Jul 04, 2017 3:43 am Woooow :o
#503 - Add ability for window profiles to match on multiple processes, captions, and classes.
Congratz on that Phil :!:
I think it's HUGE :D
Yes it could be rather good - the best thing is that are a chat with Maxoku, this solution was relativly simple to do (only a couple of hours) :).
injtsvetkov wrote: Tue Jul 04, 2017 3:43 amCan you please give us some clarification about this change when you have some time and maybe some examples about how it is supposed to work and what limitations are there (e.g. maximum number of processes in one profile or anything else you can think of).
Off the top of my head, there are no limitations on size of the string. The only thing is, the more profiles you have, the slower it will be - but if you order them in order they are most likely to be found that will help!
injtsvetkov wrote: Tue Jul 04, 2017 3:43 amThat made me realize that actually I already have 2 profiles containing "explorer.exe" which I suppose is an issue :roll:
Yes, I havnt put any checking in for he multiple profiles... It will find them in the order that they exist in the list (top to bottom). I could "fix" this but actually it may be better this way, because if it does not find the first one, the second one may be more appropriate.
injtsvetkov wrote: Tue Jul 04, 2017 3:43 am But the thing that concerns me more is how this "click and hold" functionality could also be implemented in the "chording" feature coz otherwise, using a button for "click and hold" would mean losing the ability to use that button for chording which IMO is a great limitation! Except if the "click and hold" feature is not limited to just one custom command but it has an option to show a list of commands so we could pick up the desired one by releasing the button on it!

Maybe the option to send custom command after some 'ms' could be added to the chord button. And how about sending custom command if the mouse moves while the chord button is pressed...
I wonder if I could do it all in the button chording window - as in the default button action in the chord window could have two options, default no chord and default long press... That might be easier to implement, and the fact that XMBC already has the skip if moved type options in there and the timer might just work - will have to think about that.

Thanks,
Phil

Re: XMBC 2.17 Beta

Posted: Tue Jul 04, 2017 9:52 am
by Syziph
The download link is broken.

Re: XMBC 2.17 Beta

Posted: Tue Jul 04, 2017 1:00 pm
by phil
The one at the top of this thread is working just fine from where I am right now (and that's not local to the server!)
Can you get to https://vps2.highrez.co.uk/downloads/XM ... ontrol.htm? the downloads are all hosted on that server so maybe there is a problem between you and it?...

Re: XMBC 2.17 Beta

Posted: Tue Jul 04, 2017 1:11 pm
by Syziph
Now the link worked. (B)

Re: XMBC 2.17 Beta

Posted: Tue Jul 04, 2017 4:21 pm
by injtsvetkov
phil wrote: Tue Jul 04, 2017 8:06 am Yes, I havnt put any checking in for he multiple profiles... It will find them in the order that they exist in the list (top to bottom). I could "fix" this but actually it may be better this way, because if it does not find the first one, the second one may be more appropriate.
You mean that if there are 2 profiles for the same app with different settings for the buttons, XMBC will use only the one which is higher in the list and there won't be a conflict? If so I wonder why the current "You can not add two entries for the same application." limitation, it could actually be useful in some cases to have more then one profile for an app :roll:
phil wrote: Tue Jul 04, 2017 8:06 am I wonder if I could do it all in the button chording window - as in the default button action in the chord window could have two options, default no chord and default long press... That might be easier to implement, and the fact that XMBC already has the skip if moved type options in there and the timer might just work - will have to think about that.
Well it certainly needs some thinking... if it is only in the chording then maybe it must be added to the name, something like "Button chording + Click&Hold", but probably won't be convenient for people who don't want to mess with chording and want to use the button only for "Click&Hold".
Besides that, I have the strange feeling that anyway there must be a separate timer for the "Click&Hold" so the 2 features (chording and Click&Hold) could be used in combination though I don't know if and how reliable would that be :roll:
Furthermore, have you considered adding "Click&Hold" for the chorded button too :?:

Re: XMBC 2.17 Beta

Posted: Wed Jul 05, 2017 4:36 am
by sukemaru
It is not about the function of v2.17 Beta, but I have something I want to ask.

In the "User Guide PDF" v2.16 (included also in the v2.17 Beta package), Page 13 contains descriptions about the Layer-switch sim key tags

Code: Select all

Tags such as '{Layer:<x>}' can be used to switch to the specified layer in a simulated keystroke script.
You can also use '{Layer:next}' to switch forward to the next layer, 
'{Layer:back}' to switch back to the last layer & '{Layer:previous}' to switch to the previously active layer.
Is it necessary to rewrite the tag '{Layer:back}' to '{Layer:last}'?

In the "Change log" #456 is written --'Replace {layer:back} with {layer:previous}'--, it means that {Layer: back} and {Layer: previous} correspond to the same function, does not it?
Perhaps I might not understand the function of these tags exactly, coz I have never used them (and I dont use XMBC with multiple layers effectively).

Thanks,
suke