XMBC 2.21 Beta

[phil]

Ahhh the portable version stores it in the persistent settings file I think which should be in the same folder as the executable in the portable version the installed version still uses the registry - maybe that needs to change and it should all use the main settings file... Im not sure why it does it that way (it must have made sense when I did it, but its no longer making much sense!)...

[mousetrap]

Ahhh the portable version stores it in the persistent settings file I think which should be in the same folder as the executable in the portable version the installed version still uses the registry - maybe that needs to change and it should all use the main settings file... Im not sure why it does it that way (it must have made sense when I did it, but its no longer making much sense!)...

Ah, okay -- I do see that stored in the Persist.xmbcps file, and for some reason it didn't sync properly the first time (before I started XMBC on the other computer). Seems like I'm good to go now, so it is up to you if it feels worth it to consolidate that data into the main settings file. Also, I can relate to having random work-arounds from ages ago and not remembering why I did it that way!

[maxoku]

Could you fix 2 things that I think weren't in the past?

1. When clicked on a profile with right mouse button the the profile is not chosen unless clicked on the list container with left mouse button. It might be very confusing which profile is chosen at the moment.

2. Is that Apply buttons is too sensitive for changes. Sometimes only opening some settings, but not changing anything makes it enabled. And I'm sure that long ago we were talking about it and you even made it that Apply buton disables itself if all changes were reverted back. I don't get it why it doesn't do that anymore.

[phil]

1. When clicked on a profile with right mouse button the the profile is not chosen unless clicked on the list container with left mouse button. It might be very confusing which profile is chosen at the moment.

Urm, it is for me. If I right click (which opens the popup menu) it also selects the row... Look at this...

Recording 2026-01-07 231514.mp4

Is that what you are talking about? If not, please try again in more detail...

2. Is that Apply buttons is too sensitive for changes. Sometimes only opening some settings, but not changing anything makes it enabled. And I'm sure that long ago we were talking about it and you even made it that Apply buton disables itself if all changes were reverted back. I don't get it why it doesn't do that anymore.

Which setting(s) are you referring to? Stuff in "Settings" or action configurations? In theory they should all behave in a similar fashion. I dont believe XMBC has EVER tracked the state any more than it changed since the window (settings tabs, button chording/held/simkeys etc) was opened. So if you make a change, then close the window (which highlights apply) then go back (re open the window and change it back) it will leave apply enabled. I dont remember it every doing it differently to that (but that could just be me loosing my mind!!)

[maxoku]

Is that what you are talking about?

Yes that's what I'm talking about, but it doesn't change for me, very weird.

Which setting(s) are you referring to? Stuff in "Settings" or action configurations?

I mean action configuration.

I dont believe XMBC has EVER tracked the state any more than it changed since the window (settings tabs, button chording/held/simkeys etc) was opened.

I'm sure we talked about it in the past, but was so long ago that I don't remember details. And it doesn't need to track from time the window was opened, only from last save (apply)

I dont remember it every doing it differently to that (but that could just be me loosing my mind!!)

Maybe I am losing my mind, but I really believe you made it disable apply button if the setting were changed back
Anyway other problem is that sometimes it enables apply button when no change was made, only opening setting and checking what was set.
Either way it would be really nice if it tracked if something really was changed or not to enable Apply button. I sometimes check settings, change something to see if I can make changes I want and often just go back without any changes. But then I'm getting confused if I changed anything or not, I already might forgot. There might be change I want to keep and forgot to apply before other changes/checks. By going back and seeing apply button to get disabled I would know what I changed. But if it keeps to be enabled the whole time I never will know.

[phil]

It certainly shouldn't enable apply if you didn't change anything - it should be checking that anything is different from when the configuration window opened (simkeys, button held, chording, scroll to movement etc.).

There is code that is run after the config windows close, that compares the "new" values to the old (I though it compared it to the "old when the window was opened" though, not the last time it saved - I could be wrong. Do you know if its a specific configuration window (they each have their own code) so maybe something is actually broken? Ive not noticed it myself, but I rarely change stuff here - my usage of XMBC these days its relatively simple compared to some!

[maxoku]

I've noticed that if I press ok button instead of cancel it triggers the apply button even if nothing was changed. Maybe this is what I have in mind, but can't remember details. That might have been thing that you fixed in the past, not reverting settings to disable the apply button

[phil]

hummmm, yes, I just checked on my work desktop (with a simkey macro) and the same - it enabled apply even though I didn't touch anything... That's definitely wrong! I will have to have a look and see why when I get a moment at home!

[maxoku]

I have few new suggestions:

1. It's easy to accidently scroll on drop menus to choose different actions without clicking on it and that triggers apply button immediately. If it can't disable apply button by reverting the change then maybe disabling scrolling over it should be blocked that only clicking on it would change the setting.
2. Using hover function in specific window messes up with windows even after turning it off. XMBC needs to be closed to fix it. Seems that something of its function is still not flushed after turning it off. Could it be fixed?
3. Because there always might break and XMBC needs to be closed and opened again, it would be nice to have a quick restart option.
4. I've notices new options to abort toggles. It is nice to set a key I'm toggling to abort it, so pressing it won't break it and make it stuck, but it's still not enough. What if a mouse button is toggled or more than one key? There should be an option that would use any key specified to be toggled to abort it. Because pressing any of them might break the toggle. It should also automatically abort it on app switch (when the window/app stops being active), cuz that also breaks the toggle.

[phil]

1. This is not new functionality, nor a bug per say in the current beta. I can add it to the list, but not for Beta 21. I also like the ability to scroll the list so I don't really want to disable it. I guess you are in the settings window far more than I am to worry about these sorts of (in my opinion minor) problems!

2. I need more detail - what do you mean "messes up with windows" that does not help...

3. I don't understand why you would need this, nor would it be simple to do (as only one instance of XMBC can run at a time, XMBC can not simply start another one - not without a significant change to the way it works anyway). Does Disable/Enable not fix these sorts of issues - it should fix anything related to the mouse hooks (which is the majority of XMBC stuff) - but maybe not GUI stuff like "messes up with windows" whatever that actually means!

4.You have lost me there too.. You're talking about the new simkey option to abort repeated/sticky simkeys with a specific key or when any key is pressed. I believe I have implemented it as requested behavior and as far as I can tell it was working as expected - at least in two years, I've had no complaints until now. So your going to have to be MUCH more specific in what you are trying to describe... I don't understand why it is not enough. Why would you want to abort on more than one key (but not any key)? That sounds like complexity just for the sake of it.
And any repeating simkey macro should automatically abort when the profile changes (so if the mouse moves over (or clicks) another window etc.

Are you saying that is NOT working and the simkeys are still repeating (not being released)???
If so can you please give specific configuration examples and maybe debug log showing the problem (when it is not released/stopped).


Remember, XMBC is a hobby for which I have very little time for these days.
That's part of the reason 2.21 has not been released yet (almost 3 years now). This 2.21 beta run is coming to an end (or at least I hope it is) so any new stuff wont be done in the current beta. Bugs with stuff added in the current beta is a different matter and if they are problematic and important, I will have to look at them, but if it is actually working (as intended), but not satisfying *you*, I can add to the issues list to investigate in future versions, but its unlikely I will make any changes in 2.21.

Its also might be worth noting that XMBC it old. It was started over 20 years ago now, and is written in C++/MFC (which in modern dev tools terms is also ancient!) so GUI work is excruciatingly painful/slow compared to some more modern development environments. That's not likely to change, at least not while I'm still working on XMBC! The reason it was chosen in the first place is because of its small memory footprint. But it does come with quirks and a significant time overhead to any GUI changes.


---------------------------------------------------------------------------------------------------------------------------------
Interestingly I have been looking at the APPLY button stuff today... And having gone back through time, I don't think its EVER worked as you suggested. I have made *some* improvements for the next beta version, but not as far as you would like (I know that but any more will have to wait for the next version as it will be a significant change rather than a quick fix). It will enable the APPLY button IF you change something. If you then change it back, it don't disable the apply button again until you apply/cancel! The reason for this, as I expected, it simply compares the state prior to opening the config window (simkeys etc) with the state after OK'ing the window. It does not and never has not compared to the previously saved state and to do so would require a bigger change than Im willing to make this late into the beta!
Interestingly, it only ever did this compare state in the SimKey window. Not any of the others (Chording, Button Held, Movement To Scroll etc.).
So the next beta release will be better but not exactly what you are after - that will come later as and when I find time/energy/motivation!

[maxoku]

1. I agree that's a minor problem, just suggesting. It doesn't have to be disabled completely, maybe a toggle in the setting, but yeah maybe in the future.
2. The windows are going on top of each other. I click on an icon of a window and it's not getting on top, cuz other window is already covering it. I have to click it few times that will go minimize and restore several time to bring it on top of other window. That existed for a long time, but I guess I never connected it to XMBC or forgot about it.
3. Disable/Enable doesn't fix it. If you can't make the app restart even internally then forget about it, that also is not an important problem.
4. E.g. I use 5th button with 8th method (sticky - held until button pressed again) to toggle Space. When the toggle is on and I press Space then of course Space is not held anymore but XMBC still keeps the toggle on. Meaning pressing 4th button after this won't do nothing, but disabling toggle (even if the action itself was already aborted). So I need to press 4th button twice to make it hold Space again.
   If I assign Space to abort it then the problem above is solved. Pressing Space is turning toggle off so next press of 4th button holds the Space. Don't have to press it twice anymore.
   That won't work if I make the button to hold Middle Mouse Button, cuz that option allows only a key to be assigned to abort the toggle. The same if I set multiple buttons/keys to be held with the toggle. Only one key can be assigned to abort the toggle.
   The same happens when switched to another app. Space is not held anymore, but the toggle is still on, so I have to press 4th button twice to hold Space again.
   7th Method (sticky - repeatedly until button pressed again) won't break after Space is pressed, toggle still repeat Space. But switching to another app is the same like before. Space is not repeated, but have to press twice 4th button to toggle it on again.

[phil]

The same happens when switched to another app. Space is not held anymore, but the toggle is still on, so I have to press 4th button twice to hold Space again.
7th Method (sticky - repeatedly until button pressed again) won't break after Space is pressed, toggle still repeat Space. But switching to another app is the same like before. Space is not repeated, but have to press twice 4th button to toggle it on again.[/list]

OK, thanks for the detail - it makes much more sense to me now. These two problems with methods 7 and 8 both sound like genuine bugs. When switching to another app, it should abort AND release the toggle.
I will see it I can reproduce that here (if not I'll be after a copy of your profile!) and if so, I can see whats going wrong under the debugger and hopefully fix it!

OK I can reproduce it - phew... so I will see if I can fix that for beta 56 (which I was about to release... hold!)...

As for 2. I'm still not sure I understand what is going on there... XMBC (as far as I am aware/can remember) has no code in it to modify the properties of other windows to make them "always on top"... That's definitely an odd one. is it ONLY after using the window picker? Can you reproduce it easily or is it random? If its easy, maybe you can enable debug logging, reproduce it and send me the log (along with the time that it went wrong so I can check the log around that time)?

[phil]

Hummmm, interesting. Profile detection is disabled when a sticky hold/sticky repeat is running... Thats the problem. Its an easy fix BUT I must have done that for a reason.... I'm guessing someone didn't want the profile to change while a sticky action was in place (and I can see valid reasons for that)... So I'm not sure I should just "fix" this and potentially break someone else's use-case....

And adding an option for it means more GUI work which I had kind'a rules out before the release of 2.21 :/
So I'm a bit stuck on what to do here now!

[phil]

Here is 2.21 Beta 56

Changes since 2.21 Beta 55:

• #923 - Properly stop sticky actions when the profile changes so XMBC does not think they are not "stuck" when going back to the original profile.
  NOTE: When a sticky key (repeat/hold) is running, profile detection on mouse move is paused. This is intentional but I am not 100% sure it is wise.
• #922 - Made some changes to try and improve performance problems and mouse lag (when moving).
• #920 - Fixed an issue with the apply button being enabled after button configuration, even when no changes were made to the settings.
• #917 - Fixed another couple of memory leaks/issues found in the internal Movement2Scroll/Button Held, Button Chording settings objects.

Portable version:

XMouseButtonControl 2.21 Beta 56 Portable.zip

If you ever see the XMBC bug trap crash window popup (particularly for beta versions) asking you to report the crash, please do so (hit the send report button) and if possible, also contact me here on the forums, Discord or by email so I can try and get to the issue. Whilst the BugTrap logs do often help, they don't always give enough information to diagnose and fix the issue.

As usual, feedback welcome - especially if you find a bug! Any issues/problems, Enable debug logging, make a note of the time the problem occurs and then PM me a copy of the log file (or post a snippet of the last hundred lines or so in a code block here).

NOTE: 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 ~1/3rd 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!

[maxoku]

As for 2. I'm still not sure I understand what is going on there... XMBC (as far as I am aware/can remember) has no code in it to modify the properties of other windows to make them "always on top"... That's definitely an odd one. is it ONLY after using the window picker? Can you reproduce it easily or is it random? If its easy, maybe you can enable debug logging, reproduce it and send me the log (along with the time that it went wrong so I can check the log around that time)?

Well, the windows picker is getting itself on top while making the main window hidden. It was happening every time after using windows picker. But after I installed the newest beta I'm not able to reproduce it anymore. Seems you just fixed it by accident along with something else.

Toggling off while switching apps is fixed. Toggling of while pressing the used key(s)/button(s) only remains. But if only single key was used it can be set to abort the toggle, so for most cases it will enough I guess.

Fixed an issue with the apply button being enabled after button configuration, even when no changes were made to the settings.

For most cases it's fixed, but it still can happen after ok'ing some simkeys. Weird while on most it doesn't trigger it anymore. Like on one profile when ok'ing for 5th button didn't do it, but ok'ing on 4th button did. I'll attach the profile. If it will not be enough I'll send you others or log it later.

Tomb Raider 1-3 Remastered.xmbcs

So the next beta release will be better but not exactly what you are after - that will come later as and when I find time/energy/motivation!

That's okay, fixing apply button to not trigger without changes is enough. I think this is what I had really had in mind suggesting it was fixed in past anyway. Maybe for disabling the apply button after reverting changes I only made a suggestion and you said that you might look into it in the future or something. Or maybe I just lost my mind, I'm sick so my brain is not 100% rn.

I'm sorry if I sounded pushy and ungrateful there, that wasn't my intention. I really appreciate that you still improve that awesome app, thanks.