Implicit event option

[mrallen]

I would like to formally propose the inclusion under configuration of a checkbox for verbose event generation. And it goes something like this:

* every button/key press generates an event if either (a) the button has an ID field or (b) it's a hard key. for (a) it would send "Button.<ID>" and for (b) it would send "Key.<NAME>"

* every panel transition generates an event in the form "Panel.<DEVICE>.<PANEL>". it could optionally be more explicit and include the source and destination panels.

This would eliminate the need to add special IR codes to buttons and would more easily allow for richer server-side scripting.

[QuickCarl]

Sounds like a good plan over all.... but there might be a problem because names are not required to be unique...

Seems like there still needs to be a way to tell the different drivers whose buttons belong to whom.

Having said that... I always like to hear people thinking about how to make things better. BTW Mr.Allen... thanks for Tonto... I am a convert!

[mrallen]

Button ID's are unused by the CCF (they are distinct from the Name/Label) and perfect for the task. Right now you have to have a unique IR label, the same would apply to Buttons IDs. The advantage is that the Button ID is part of the button data structure. You don't need to open the action list, add IR (not obvious) and hand-enter a cryptic set of hex codes.

[brockgr]

Stewart,

I'm curious about what you are hoping to do with this. Is it for debugging, or an alternative interface?

Couple of things - would this be configured in the Girder-plugin for NR or in the CCF.

Also, if this is going to Girder (or a Girder-like interface), it would probably be better to but the variables (ID, NAME, DEVICE, PANEL) into the event payloads than the event name.

Cheers, Gavin

[mrallen]

Oh, so you want to know my evil plans, eh? Maybe I should start charging admission. :idea:

I was thinking this would be a NR config option. Whether it's global or part of the Girder plugin-in is not too important. I'm also not too concerned about the format of the event as long as (a) I can get it and (b) I can parse it.

And the *reason* I want this is plain usability. Or sheer laziness. Your call. It's just that adding/editing all of those IR codes is a time-consuming mess. Most of my CCF buttons will be events I care about on the server-side. And the event is easily enabled/disabled just by clearing the ID.

[Ben S]

Ah-ha! Now's my chance to bring up what I did in C#, but would like to see supported in Tonto.

In my C# version (never released), I opened a Girder .gml file along with a .ccf file. I allowed the user to drag a Girder action from the gml tree to the ccf button. This would ...

* Set the ccf button to girder, with event ID as configured in Girder if it was already configured as an IES event.

or

* Create a new IES node in the .gml file, and enter the correct info into the .ccf.

This was pretty neat, and something I would love to be able to do again (within Tonto). Even neater would be if you could have an .xml file (for non Girder events) with driver id, command id, data id and a description, which you could drag and drop onto a ccf button in Tonto.

For instance, I download the MJB driver. It comes with an xml file for all the things supported in it. I open that up in Tonto, I see a list of ...

Album Title
Track Title
Artist
etc.

And I can drag "Album Title" to an existing ccf button for it to change the internals to be correct, -or- it creates a default button with it set. Maybe it could prompt you for the IR / Button name if something in the XML said it was important info?

That would -really- be awesome.

What do you think, Stewart? Too much of a pain? Not enough benefit? This would shoot to the top of the priority list if it's something you'd like to do.

[mrallen]

I'd have to spend some quality time with the gml format. This is a lot harder than some things I'd like to get done first, but definitely work pursuing.

[Ben S]

Great. I would think the "generic xml" route would be easier than the gml format issue. Either way, this would definitely lower the barrier of entry into the NetRemote / Tonto world.