Teddyboy wrote: ↑Mon Feb 08, 2021 5:01 pm
You mentioned that the registry still having buttons configured for the remote. Is there any fighting between your solution and the registry?
Yes, currently they fight. It only works correctly if you configure a button that otherwise does nothing. Which could actually have some interesting applications - imagine having a button "A" configured to do "X" in the registry, but configured to do "Y" in my app. Press A and get both X and Y. Is there a valid use case for that? Probably not.
So for right now, I'm only testing buttons that otherwise don't do anything. It's also possible to successfully configure buttons to do things in CMC, that otherwise do stuff in other apps but not in CMC. For example, "Record" does nothing in CMC, but activates the Record function in HDHomeRun. I can configure it to do something only for CMC, and the existing behavior in HDHomeRun is unaffected.
To be able to configure and control all buttons, you have to disable the HID input for all of Windows, which then makes my app 100% responsible for monitoring keypresses and issuing commands. Yikes. But I think that this is ultimately what some users will demand.
Teddyboy wrote: ↑Mon Feb 08, 2021 5:01 pm
Have your tried this with other apps that interact with CMC such as any of the players you support?
Yes, a little bit. It seems to work similarly in other apps - as long as the button doesn't already have an action, you can configure an action for it. But if it already has an action, configuring a second action would produce competing actions as you suggested.
I haven't tested PowerDVD yet - that app is notoriously bad about stealing button presses and hiding them away from the rest of the system. I'm thinking my new app, since it ties directly into the MCE IR6 driver, will overcome this issue.
Teddyboy wrote: ↑Mon Feb 08, 2021 5:01 pm
Sometimes I will press the wrong button and jriver will pop out of display view.
The only solutions are to either A) disable MCE remote HID input via the Registry for all of Windows (making my app or something like EG/Girder 100% responsible for monitoring buttons and issuing actions), or B) modifying the Registry to disable just those buttons so they have no action, then you could remap them using my app and make them do what you want.
*NOTE: method A is what EG recommends, but my app isn't to the point it could take over 100% of all actions.
Without registry tweaks, then the only thing my app could do is allow you to assign a secondary competing action for the same button, making the problem twice as bad. You know, for masochists...
Teddyboy wrote: ↑Mon Feb 08, 2021 5:01 pm
You did mention that you probably would offer a option for either using registry configuration or do it through the service. Personally I would opt for the service for my install, as it appears to be much more responsive and configurable.
The more I develop it, the more I really like the new service. I will definitely be abandoning the Registry approach for my own personal use. And I'm already expanding the functionality much more than I originally planned because it has so much potential.
That said, I'm not ready to pull the plug on the Registry based solution for existing users, since the new solution hasn't proven itself yet. Typically I prefer to leave working tools in place for users who prefer them. Similar to what I did for CCC vs. CME.
Teddyboy wrote: ↑Mon Feb 08, 2021 5:01 pm
Would you consider having profiles for the supported player.
Yes. In fact, I'm already coding this. I spent a few hours doing data design just trying to figure out how I want to store all this configuration data. And I have a pretty strong concept drawn up, but there is one aspect I haven't quite figured out. Let me try to describe it so you (and others) can comment on how you think it should work.
The Concept
Button configuration will be organized as Modes as the parent, and Buttons with Actions as the children. Modes are mostly apps, i.e. CMC, PowerDVD, JRiver, MPC, HDHomeRun, but I also have a special Mode called Global. Each Mode will have it's own configuration page, so you can configure the buttons you want for CMC, then switch over to JRiver and configure the buttons you want there. Ditto for Global.
Global buttons currently take precedence - if you configure a button in Global, it would not be available to configure in any other app Mode. A good example of this is the "Start" button (aka The Big Green Button). If I assign it to launch CMC, then no matter where I am or what app I'm using, pressing Start will launch CMC. Another good example of a Global button is the Close action - perhaps you assign the "Red" button to be Close, and no matter where you are, pressing "Red" issues the ALT+F4 close action.
Then for buttons that you didn't assign on Global, you can assign to each app Mode to do different actions as desired. For example, you might configure "Live TV" to switch to the "Show Media Type TV" filter in CMC, but switch to Live TV in HDHomeRun. Since the app will know which program you're currently using, it can apply the correct action for that Mode.
The Gap
As fairly complete as the above concept is, I feel there is one scenario that isn't handled. I'm not sure what to call it, but the best way to describe it is a Global button that get's overridden by a Mode's configuration, so kind of the opposite of a Global.
For example, let's say you want to make the "My TV" button always launch HDHomeRun, unless you are in CMC where you want it to switch to the "Show Media Type TV" filter. So the Global action is to launch HDHomeRun, but it get's overridden by CMC's configuration for that same button.
Essentially, what I'm describing is two types of Global buttons, Global Static, and Global Overridable. (Yeah, I hate my terminology too. Please feel free to help me with the lingo). The question is, how do I design my app to let users define this configuration?
One idea is to have two global tabs: Global Static and Global Overridable, but I think this might be confusing. This config page will be set up with tabs across the top, so it would look something like this:
Code: Select all
Global Static | Global Overridable | CMC | DVDFab | JRiver | HDHomeRun | MPC | PowerDVD | VLC | etc...
-------------------------------------------------------------------------------------------------------------------------
The other way would be to add a toggle to each Global assignment to either make it overridable or static, more like this:
Code: Select all
[GLOBAL] | CMC | DVDFab | JRiver | HDHomeRun | MPC | PowerDVD | VLC | etc...
------------------------------------------------------------------------------------------
GLOBAL BUTTON CONFIGURATION - APPLIES TO ALL APPS SYSTEM WIDE:
Button "Red" - Action "ALT+F4" - Overridable: No
Button "Start" - Action "Launch CMC" - Overridable: No
Button "Guide" - Action "ALT+G" - Overridable: Yes
That's a high-level of where I am, and the last real design challenge I'm working through. Though the act of writing all this out has helped me think through it again, and I'm leaning towards the second method, having an overridable toggle on each Global button assignment.