Full keyboard mapping support

[z.mash]

Hi Ben (and Stewart),

I assume the 1.0 release feature set is locked down, so I'll put another request in for 1.x. I would like to be able to map more hard buttons to NR. I just bought a new tablet-style PC (see this thread (http://www.netremote.org/phpBB2/viewtopic.php?p=1002#1002)) that has a numeric keypad on it. I would love to map those keys to trigger events in NR.

-Zak

[QuickCarl]

Zak - why cool looking unit. Let us know when it arrives and you get a chance to take it for a spin. -Carl

[mrallen]

Rather than clutter the CCF format with these additional keys, it might be cleaner just to pass them as '0'-'9' raw key events to the server and let the server (girder or whatever) deal with it.

[z.mash]

Because the keys would need to do different things for different panels. If I am on the Tivo panel, they will operate that. If I am on the HD panel, it would control that device.

I know I am in the minority here, but I am wondering if there is some "easy" solution that doesn't involve major overhauls. I definitely don't mind more work on my end to make it happen.

-Zak

[z.mash]

I had another thought - if Girder could somehow "know" what NR is on (maybe through feedback?), I could use LUA to trigger the proper event. Is this possible (and if so, is it easier)?

[mrallen]

This is one of my requests. Actually two. First, to send events when a panel transition occurs. This allows you to keep state on the server-side. Second, have key and button events include a qualified "path" to that button. Something like [DEVICE][PANEL][KEY/BUTTON].

[Ben S]

What if I send the DEVICE/PANEL/BUTTON as payload 2, and move the possible parameters down? Payload 1 should be the IP address (Girder does that), payload 2 would be DEVICE/PANEL/[BUTTON|KEY], and all other payloads would be other parameters?

Then adding an option to Girder to pass "non-handled hotkeys" to Girder (using the above) would do what you need.

[brockgr]

Sounds good - but it's the kind of incompatible change that should be done sooner rather than later. I would also vote for a similar message on all panel changes.

The only issue would be how much performance impact this change would make.

Cheers, Gavin

[z.mash]

So, this would involve using LUA in some fashion to keep track of the active page, and then to capture the incoming button press and then execute the appropriate Girder command. Is this right?

Thanks,
Zak

[Ben S]

Sounds good - but it's the kind of incompatible change that should be done sooner rather than later. I would also vote for a similar message on all panel changes.

Good point. What if there was another Girder action type, that sent the device/panel/button (key) name as the payload.

Then if there was a setting for default non-ir action handler, you could set Girder as the default if no driver is specified, or when an key is hit that isn't tied to a hotkey, etc.

This would leave current compatibility, and extend the featureset. What do you think?

[brockgr]

Ben,

You're losing me now.. "setting for default non-ir action handler" :shock: ?

Are you suggesting a new IR code range for this?

Gavin

[Ben S]

You're losing me now.. "setting for default non-ir action handler" :shock: ?


Basically a "catch all" for any button which doesn't have an action assigned. Right now all IR data (that's not handled by a specific driver) is passed to the "default IR handler" id -3 (NRIRServerDrv).

[brockgr]

Okay, I think I'm getting it - we have a choice of "default handlers". The user can choose either to have NRIRServerDrv as the default, or some new Girder style driver.
Right? Gavin

[z.mash]

I think I have a temporary workaround. I created a series of Girder Commands



- NR State
-- NoState (EventTrigger: ResetScript)
-- SwitchToDVD (EventTrigger: NRState.DVD)
-- SwitchToHDTV (EventTrigger: NRState.HDTV)
-- SwitchToTivo (EventTrigger: NRState.Tivo)


The first sets a variable called "zNetRemoteState" to "NOSTATE", and the subsequent commands set the state appropriately. In my CCF, anywhere I have a jump that changes devices, l will first send a command with the appropriate state change.

The hard buttons are then setup to call Girder Commands as follows:


- 6642 Hard Buttons
-- Choose0
-- Choose1
-- Choose2
-- Choose3
...
-- ChooseEnter


Each of these contains a series of "if...then...else" statements that resolve to the appropriate LUA "TriggerEvent" statement. For example, if I am in the Tivo screen and hard button 1 is pressed:



if (zNetRemoteState == "TIVO") then
TriggerEvent("Tivo.1", 203)
end


Ben - will the change you are proposing obviate the need for me to communicate movement between panels to Girder? That is, I will still need to have the above code in place to handle the event that comes in, but I won't have to put commands in the CCF to tell Girder that I have moved to a new panel.

Thanks,
Zak

[Ben S]

I'm not sure now what I'm thinking. I'll get back to you on how I think this can tie in easier.

[Eiffel]

It would be great if NetRemote could send a message with the [Device] and [Panel] information each time either the device or the panel changes on the remote.

This, combined with the feedback mechanisms would allow to always have girder and the remote 'in synch', a feature I would really like to have ;)

(This would, among other possibilities, allow to consistently launch an application on entering a given panel. This would also provide a confirmation that some girder feedback commands have taken effect...)

[brockgr]

One thought - could this behaviour be made a property of a panel, rather than a global setting for NetRemote. This would mean that panels that need this could use it, without breaking the compatability of curretn users.

Gavin

[Ben S]

Good idea, Gavin.

What about having a event string on a button that would send the current driver and panel when the button is "registered" with NetRemote.

This is a little hokey, but could be -any- button which doesn't need to specially register for anything else (a jump button, or one of the new feedback buttons, etc.)

This could even be a hidden button with a very small size.

This would allow for any driver to "catch" the panel change, instead of just Girder.

What do you think?

[brockgr]

Sounds a little cheesy, but would probably work. It would be nice if it was possible to create properties of panels, rather than devices. Currently the only property you can set is "Hidden" which isn't much use.

It's interesting how much of the devlopment of NetRemote involves requesting enhancements to Tonto, or working around current limitaions. Stewart has been really helpull, but I think we could keep him in full time-employment with feature requests.

Anyway, keep up the good work/ideas!

Gavin

[Ben S]

Hopefully when Stewart gets his machine up and running again, we can start to turn some of these great ideas into reality.

For instance, the sliders in the new version. It would be great if it Tonto it would prompt for the thumb image, and allow you to enter min,max and current values, and it would create the slider "object" for you.

This issue (panel transition information) is not resolved in 0.99, but as Zak has found a way to do this in Girder for now, maybe we're all set.

Also, with the new variable system, what if the device and panel were variables, and the Girder driver could be subscribed to them. When they changed, the Girder driver would send that info? Perhaps only if the flag is set on the panel?

-Ben

[z.mash]

Yes, I'm set. It's a bit of a kludge, but not too bad. I just have to remember to send a Girder command with the panel name before I do a jump. Once that is in place, Girder handles the rest!

-Zak