IR8.01 Beta posted

Post by **ElizabethD** » Sun Jul 12, 2009 7:59 pm

I haven't yet downloaded 8.0.3 and just read the wonderful debate over the keymove naming of columns. It all sounds good to me (best is source and target IMO).
Just FYI, bit of trivial historical perspective using UEI manuals:
6131: source mode, source key, destination mode, destination key
HT-Pro Plus (9910,8910): from mode, from key, to mode, to key
7800: I have some sort of pdf, no mention of keymoves other than ressigning device keys. Go figure.
I like to retain the "=". I recall ages ago it actually helped me square what I saw in KM and IR for 8910 vs doing it on the remote's LCD.

Post by **mathdon** » Mon Jul 13, 2009 2:24 am

I think we may all, myself included, be forgetting the importance of context. The C language recognises this by referring to the l-value (left value) and r-value (right value) of a symbol, rather than simply its "value". In the assignment statement "x = x + 1", the l-value of x is a memory location, the r-value is a number. The assignment increments this number by 1 and places it in the memory location.

In the same way a key name such as "Mute" or "SAT" or "3" has an "l-value" that is a key (or button) and an "r-value" that is a command (or function). All of the Advanced Code tab entries are assignment statements (we even have the "=" sign

) that assign a command to a key. I see no problem and several advantages in using a different word, "key" v "command", for "Mute" or "SAT" or "3" depending on whether it is the l-value or r-value that is being referred to.

I concede on the issue of whether xshift-phantom6 is or is not a key. That was mdavej's example and I stuck to it. It has an l-value (ie it can be a target key) and so is a key, even though it is phantom. But I would still dispute whether X_DEV1, say, is a key in any sense. Nothing can be assigned to it as it has the "AllBind" button restriction in the RDF. It has no l-value, so is not a key. It is like the "1" in "x = x + 1", a constant r-value command. My extender has 66 keys (assignable, including phantom ones) in the RDF but 75 constant commands. Surely there is merit in distinguishing the two.

I know that within the extender code such keys and constant commands share a common encoding space, but this is for convenience only. I don't think user terminology should be based on the internal operation of an extender.

I have no particular views on key v button, but I've just checked my old URC-8550 manual and everything there is called a key, including "device keys". "Key" has the merit, too, of being shorter

. In JP1-speak, button seems mainly to be used for "Device Buttons", other things being "Key Moves" etc.

More comments please!
__________________
Graham

Post by **The Robman** » Mon Jul 13, 2009 10:55 am

IMHO, "key" and "button" are interchangeable and they both refer to buttons on the remote, be they device buttons, regular buttons or even phantom buttons. (The word "phantom" explains that the button in question is not a physical button). "Key" has the advantage of being the word that UEI typically uses in it's manuals, "button" has the advantage of being painfully obvious.

As for the extender device modes, I agree that they're not really buttons or keys, but as they get treated as buttons for the purpose of building a macro, I certainly don't object to them being called buttons or keys.

I also have no problem with the word "steps" being used in the context of building a macro.

Here's a wild idea for you guys, if you have a spouse or kid who's not that much of a techie, ask them their opinion. Sometimes it's hard for those of us that are this close to it to know what's obvious to the rest of the world and what isn't.

Mark Pierson · Post by **Mark Pierson** » Mon Jul 13, 2009 1:50 pm

The Robman wrote:IMHO, "key" and "button" are interchangeable and they both refer to buttons on the remote, be they device buttons, regular buttons or even phantom buttons.

I've always looked at it this way: "keys" are part of a keyboard (i.e. PC, etc). It's "press the ENTER key", "press the "HOME" key, etc.

"Buttons" are part of a keypad (smaller than a full-size key board, i.e. rmotes, telephone, security panels, ATM's, etc)). "Press the PLAY button", "press the VOL+ button", etc. What do you need to do when you want to pause your DVR? You press the PAUSE button.

In the end, it's all semantics and personal preference (and really doesn't matter what they're called).

Here's a wild idea for you guys, if you have a spouse or kid who's not that much of a techie, ask them their opinion. Sometimes it's hard for those of us that are this close to it to know what's obvious to the rest of the world and what isn't.

If my wife and/or kids were techies, they wouldn't need me!

If I ask what they thought about this subject, I'd get some pretty strange looks and probably be on my own for dinner tonight, too!

I think since IR is Graham's baby now, he should go with what he's comfortable with, keeping in mind the impact any changes are going to have not only on us "experts", but the documentation, etc, that newbies have to wade through when starting out in JP1.

mr_d_p_gumby · Post by **mr_d_p_gumby** » Mon Jul 13, 2009 1:55 pm

mathdon wrote:In the same way a key name such as "Mute" or "SAT" or "3" has an "l-value" that is a key (or button) and an "r-value" that is a command (or function). All of the Advanced Code tab entries are assignment statements (we even have the "=" sign ) that assign a command to a key. I see no problem and several advantages in using a different word, "key" v "command", for "Mute" or "SAT" or "3" depending on whether it is the l-value or r-value that is being referred to.

So how would you handle the short-form keymoves used in all the recent remotes where the target r-value is not a function but an actual key? Such a keymove would be created on the remote itself, the user having followed UEI's instructions to "move" a key. IR has no way of determining the function of the key referred to if it is defined within a resident setup code, so I don't see how you could translate the key into a function.

Post by **mathdon** » Mon Jul 13, 2009 2:50 pm

Mark Pierson wrote:
The Robman wrote:Here's a wild idea for you guys, if you have a spouse or kid who's not that much of a techie, ask them their opinion. Sometimes it's hard for those of us that are this close to it to know what's obvious to the rest of the world and what isn't.
If my wife and/or kids were techies, they wouldn't need me!

If I ask what they thought about this subject, I'd get some pretty strange looks and probably be on my own for dinner tonight, too!

Absolutely!

mr_d_p_gumby wrote:So how would you handle the short-form keymoves used in all the recent remotes where the target r-value is not a function but an actual key? Such a keymove would be created on the remote itself, the user having followed UEI's instructions to "move" a key.

The key is still acting as a function, just as the compiler of "x = x + 1" doesn't know what the value of x is on the right, but it knows that it is the current contents of a memory location, not the address of the memory location (which is the meaning of the x on the left).
________________
Graham

Post by **vickyg2003** » Mon Jul 13, 2009 3:10 pm

The key is still acting as a function, just as the compiler of "x = x + 1" doesn't know what the value of x is on the right, but it knows that it is the current contents of a memory location, not the address of the memory location (which is the meaning of the x on the left).

I've been trying to get my head around the idea of a button as a function, and I can't think that abstractly.

Here's a wild idea for you guys, if you have a spouse or kid who's not that much of a techie, ask them their opinion. Sometimes it's hard for those of us that are this close to it to know what's obvious to the rest of the world and what isn't.

Isn't that what you keep me around for

Post by **mathdon** » Tue Jul 14, 2009 2:37 am

There is clearly zero support for the use of "commands". Even the Capn hasn't voiced support for what I have done, and that was his idea. So it will all revert to what was there before, even meaningless headings like "Short Keys" and "Long Keys". I'll leave Target instead of Bound, as there seems at least some consensus to eliminate Bound, and will make the second Dev Btns column of Key Moves be "Source Device" as apparently the least objectionable option.
_________________
Graham

Capn Trips · Post by **Capn Trips** » Tue Jul 14, 2009 5:38 am

My silence doesn't mean that I don't care. It means that my last stated position is unchanged.

I prefer "Commands" but am not so attached to it that I will boycott IR if that is not used.

Post by **mathdon** » Tue Jul 14, 2009 8:36 am

Capn Trips wrote:I prefer "Commands" but am not so attached to it that I will boycott IR if that is not used.

I prefer "Commands" too, but am not so attached to it that I will stop developing IR after backtracking on the headings issue.
________________
Graham

Post by **The Robman** » Tue Jul 14, 2009 8:58 am

When I'm describing how to do program a keymove on a remote, I'm careful to refer to 994 as a "command" because up until now we haven't used that word in place of function, button or key.

I haven't read all the recent posts as I'm on vacation at the moment, but if we start referring buttons or functions as "commands" how should we refer to things like 994, etc?

Capn Trips · Post by **Capn Trips** » Tue Jul 14, 2009 9:06 am

How about just "Sequence" without any prefacing modifier?

"Short Sequence"
"Long Sequence"
"Macro Sequence"

etc.

Post by **vickyg2003** » Tue Jul 14, 2009 9:13 am

if we start referring buttons or functions as "commands" how should we refer to things like 994, etc?

Very good point.

Also if we start referring to buttons as functions, it would add even more confusion to RM and KM, where we assign functions to buttons. It hasn't been that long since I first struggled to get my head around upgrades. If we started referring to buttons as functions, how on earth would you describe KM.

Capn Trips · Post by **Capn Trips** » Tue Jul 14, 2009 9:48 am

Let's call them "quatlus"

Post by **The Robman** » Tue Jul 14, 2009 10:27 am

To me, the separation of "functions" and "buttons" has always been an important factor in understanding upgrades, so those should stay "as is". Macros have always been a sequence of buttons (or "steps" where steps are buttons), so even a non-JP1 user should be able to understand that.

Obviously, we've complicated macros by introducing phantom buttons and the X_DEV type extender modes, but both of those are acting like buttons, so I don't see the need to rename things on their account.

Like I said, I haven't really been following this discussion, so I don't know what initiated this, but here's my summary...

Buttons (or keys) = physical buttons on a JP1 remote (including things acting like buttons, i.e. phantoms, etc)
Functions = functions of the OEM device (ie, buttons from the OEM remote and discretes)
Commands = 994 type features of a UEI remote.