EventGhost

partly stolen from Girder...

Basically, you 'define' a "remote control" - all this is, is a set of IR commands you assign a name.

Then when you define your actions and you want to use a remote command (send/receive, trigger on, etc) you simply pick the remote's "Name" and the associated command you want to use... example: XBMC / Pause

This can be drag-n-drop from a list

This has many benefits...

1) if you change the IR signal for that specific command, nothing else changes... all your references are still good.
- so if you change more controls you can simply learn the IR commands into the existing defined remote and no need to change anything else
2) allows your 'Remote Definition' to contain IR commands from multiple devices... think just like the Harmony does.

3) Allows 'define once use many'

and one of the coolest features (this was my idea - not stolen)...

4) If EG allows setting a default remote... then any plug-in that points to the default will AUTOMATICALLY work without ANY SETUP!


thoughts?

I already do something like this. I have a node called "event translation" and a sub-node for each remote. Under each remote is a node for each raw event from the USB-UIRT, which is then translated to things like "Num1", "Play", etc. The only problem with this approach is that "autorepeat current macro" doesn't work with this approach.

- Jeff

Livin,

This is my first post, but I've been reading through the forums for the last few days. I've also developed a couple of plugins.

I also think there should be a simpler way to configure eg.

Towards that end, I've been changing some of the core code to support my idea. I was hoping to get a prototype soon to show Bitmonster (I'm close, but not there yet), but your post was so timely, I thought I make my first forum post here.

Here's my proposed solution:
1) Have a list of which events a remote can emit. My first plugin is a remote plugin for the remote (the remote for the Zalman HD160-XT case, which didn't have a plugin). Once I had it working, I added one line of code, to store a list of events the plugin could emit ("Play", "Pause", "Num1", etc).

2) Add an "AutoConfig" command. I'm adding a new command to MainFrame's __init__.py.
Note: Bitmonster - I tried to do this in a plugin, but it kept crashing. I think it needs to run in the gui thread, and I wasn't able to find a way to get it working without going to MainFrame. I hope you don't mind!
AutoConfig works like the createMacrosOnAdd parameter for plugins, except when it creates the macro, it looks at the list of possible events and adds the event to the macro if there is a match. So for instance, the TheaterTek plugin has a "Pause" action, and the remote has a "Pause" event, so the macro that's built includes both the event and the action - automatically created.

Thoughts?

Brett

stottle... great minds think alike!

Ok, I've got something working. I'm starting small, so don't expect too much yet. Also, there's no installer for this, you need to be fairly comfortable with how eg works to get this up and running.

Bitmonster's done a great job on eg, so Undo works on changes my code makes. Eventghost will also ask if you want to save any of the changes, so you don't have to change your config unless you want to. That's true of the configuration xml file, obviously changing the eg code baseline with my code is risky!

I have updated the core by adding a new function: AutoConfig. This will show up on the main window for eg, after the addplugin/addaction buttons on the menubar, as well as when you right click. It has a plugin icon with a magic wand overlay.

In order for the function to work, you need to include the AutoConfigure plugin. Right now, all this plugin does is read a list of xml files on the AutoConfigure plugin directory and create a set actions (of keyboard shortcut for each app) from each file. Right now I only have a test file for TheaterTek and TotalMediaTheatre. At some point you should be able to point to other plugins, but not yet.

So the process works like this: With the AutoConfigure plugin loaded, action groups are created when eg starts. One action group for each xml file in the directory. These groups look for the active window of the desired app (using WindowMatcher), then send a key sequence. The action groups will exist in eg, but not effect your system - they aren't loaded anywhere unless you add them manually or run AutoConfig

After startup, you have
AutoConfig.TheaterTek
=>Play => "{P}"
=>Pause => "{Space}"
=>Exit => "{X}"
=>etc..
AutoConfig.TotalMediaTheatre
=>Play => "{Space}"
=>Pause => "{Space}"
=>Exit => "{Ctrl+X}"
=>etc..

Next, you hit the AutoConfig button. This works like the CreateMacros function does, with one exception. Before it starts creating macros, it reads all of the loaded remote plugins. It creates a list of all of the events in each one's plugin.info.eventList.
Note: Right now, I don't think any of the remote plugins set the eventList. For most (if not all) plugins, this can be fixed by adding a few lines to the __start__ function of the remote file.

For plugins that use a KEY_MAP disctionary: For plugins that use a KEY_MAP list: Once this list is created, the macro creation runs. It creates a folder for AutoConfig, then a subfolder for each app. Then under each app, a macro is created for every available action. Here's the new part. If the name of the action is included in the available list of events (So TheaterTek has a "Play" action, and one or more remotes has a "Play" event), the event is automatically added to the macro with the action.

I'm really hoping Bitmonster likes this idea and is willing to update the remote files and core to add this functionality. That way you don't need to manually change the remote files and update the core.

Once these macros are created, the apps will start responding to remote keys. All the new users has to do is load a remote plugin and click the AutoConfig button and he/she can be up and running! No more triggering each event and manually dragging to the appropriate action! You will have to manually configure non-standard actions.

Instructions:
The attached zip file includes all of the files changes. It will uncompress to a folder structure that resembles eg's. Just add (or replace) the files to your eg directory (make backups, of course) and restart. Don't forget to make and eventList for your remote, too. Then restart and give it a try.

I hope a few people will give it a try (especially Bitmonster) and let me know what you think.

Brett

If you can work with the XBMC plug-in from jonib then I can test it.

btw... don't forget to allow for the possibility of multiple remotes Remote1.Pause , Remote2.Pause

I hope BM will help out and integrate it in the core of EG.

awesome work bro!

Ok, I've updated this quite a bit. There is no AutoConfig plugin anymore. The code will now look through the installed plugins instead.

When it finds an installed remote plugin, it will add the events stored in the plugin (if any - see the comments two posts below for how to add for your remote). When it finds an installed program plugin it will create a folder of macros for each action (just like createMacros does). However, it will try to match each action against the list of remote events (it compares the action __name__ against the event string - __name__ is the first string used if the program plugin used AddActionsFromList). If there is a match, the event and the action are added to the macro.

What does this mean? If you have an installed remote and several applications, this command will create "active" macros automatically when the remote event matches the program action. By "Active", I mean a macro that has an event that can be triggered from the remote, joined to an action that affects a program. This works well for the common cases - "Play", "Pause", "Up", "Down". This should be good enough to get you up and running with your favorite media players!

When run, this creates a AutoConfig folder in the EventGhost tree, with sub-folders for each application. Under each application folder, the macros are created. So this shouldn't overwrite any existing configs (unless you have an AutoConfig folder already).

Tested against XBMC - works like a charm!

Next, I'm trying to create custom icons so you can easily tell which macros include events and which don't. Unfortunately, I still don't know if Bitmonster is on board with this. I sent him a PM, but haven't heard anything back.

Still immature, but I'd still love to get some feedback if people are willing to give this a try.

Brett