New IR file format

Nils_Ekberg · Post by **Nils_Ekberg** » Wed Apr 21, 2004 9:42 am

e34m5 wrote:This was per Mr. Nekberg's request. You are correct that officially it does not need that much detail. Nils has some ideas of how that may be able to be used in the future. I guess it's no harm.

Paul is correct on my request. What I was looking to do is include as much information as possible with each keymove so in the future we could look at the possibility of using the info to be able to remove a keymove that was associated with an upgrade if it is no longer be needed.

An example of my thinking would be when someone creates an upgrade for say TV and it generates a lot of keymoves because the buttons are not in the TV map. They then change it to Cable and the codes are then on mapped buttons we should be able to get rid of the OLD keymoves.

This is not completely thought out yet so it will be a future enhancement.

Mark Pierson · Post by **Mark Pierson** » Wed Apr 21, 2004 10:03 am

Nils_Ekberg wrote:An example of my thinking would be when someone creates an upgrade for say TV and it generates a lot of keymoves because the buttons are not in the TV map. They then change it to Cable and the codes are then on mapped buttons we should be able to get rid of the OLD keymoves.

I don't want to side track this thread, but there are at least 2 reasons why this likely won't work in this context.

One, not every key move will have a note associated with it. Currently, only a key move with a note gets an entry in the saved file. Second, not every key move is necessarily created as part of a device upgrade, and therefore can't or shouldn't be deleted because a device type was changed. IR would need some other method to accurately track something like this.

That said, I would recommend that notes entries in the IR file be kept as simple as possible (i.e. <BoundDevice>:<BoundButton>=<note>). As happened with the RDF's, there's no reason we can't extend this new IR file format as we dream up new features in the future. IMHO, what you're suggesting goes beyond what I think the notes feature should provide (though I do agree with your concept for that feature).

Nils_Ekberg · Post by **Nils_Ekberg** » Wed Apr 21, 2004 10:22 am

The thought was that if this was a viable solution all keymoves would be saved in the file even if they did not have a note associated. If this won't work then so be it, we can remove the extra information and figure out a way to save information related to keymoves associated with an upgrade some other way in the future.

Mark Pierson · Post by **Mark Pierson** » Wed Apr 21, 2004 11:43 am

Since this topic warrants some discussion, I've split this into its own thread.

Nils_Ekberg wrote:If this won't work then so be it, we can remove the extra information and figure out a way to save information related to keymoves associated with an upgrade some other way in the future.

Sure, it could work that way, but is that the best solution?

The only time deleting the key moves becomes an issue is if the parent upgrade is deleted. You can't really change the device type of an upgrade in IR (even though there's a device selection dropdown in the Devices dialog) because the key map details are going to be different from one type to another.

I think John mentioned at some point handling an upgrade (including associated key moves) loaded into IR as an "object". With that in mind, I suppose the data that's pasted into the Devices dialog from KM or RM could be saved as an item in the IR file. Then, if that item is later deleted, IR can check to see if any of the defined key moves still exist, and if they do, offer the user the opportunity to delete them as well.

We're probably getting way ahead of ourselves here discussing major changes such as this to IR at this time, though it should be added to the "wish list".

johnsfine · Post by **johnsfine** » Wed Apr 21, 2004 12:19 pm

I think I made some comments recently (I forget in which thread) about certain information in the KeyMove entry being unnecessary because it is redundant with the KeyMove itself. If did say that, I was wrong.

As Nils is saying here, we want that KeyMove entry to include all the information needed to reconstruct the actual KeyMove (I haven't checked whether it already does) and we want to be able to include KeyMoves that don't have notes.

One goal is to allow bulk (from KM, RM, ExtInstall) insertion of too many KeyMoves without directly breaking. The user can then clean up enough KeyMoves and Macros to get back to a working config. I think that would be much easier for the user than preventing them from doing the bulk insert that doesn't fit.

Nils_Ekberg · Post by **Nils_Ekberg** » Wed Apr 21, 2004 12:24 pm

I was actually getting ahead of myself when I asked Paul to add the extra info. I just wanted to get it in there as a place holder while some coding was going on. It was on John's wish list and one of my favorites also.

I did realize that all keymoves would have to be saved even if they did not have a note. Paul and I discussed this and had decided that the delete function would be way down the line so it was not worthwhile doing the save now and just turn it on later if/when we did something with keymove deletes.

Yes, I understand that device type can NOT be changed in IR but was assuming that the keymove deletes would be needed if:

1) a device was completely deleted or
2) a device was replaced by one with a different device type ie. button map.

I think what you are saying about loading an upgrade as an object and at that time make an entry in the file which would include the reference to the associated keymoves that were there at the time of installing. That in the end may be better than what I was thinking which was something like:

1) Save all keymoves to the file not just the ones with notes.
2) When a keymove is manually entered flag it as ADDED.
3) When a delete of the upgrade is done delete the keymoves that are not flagged as ADDED.
4) When an upgrade is replaced do the same as 3.
5) for 3 & 4 a confirmation prompt should occur just incase the user does not really want to delete the keymoves.
6) Prompt for deletion of the ADDED keymoves that are associated with an upgrade that is being deleted.

Nils_Ekberg · Post by **Nils_Ekberg** » Wed Apr 21, 2004 12:28 pm

johnsfine wrote:I think I made some comments recently (I forget in which thread) about certain information in the KeyMove entry being unnecessary because it is redundant with the KeyMove itself. If did say that, I was wrong.

Not a problem John since you only said it to me in e-mail when I was trying to convince you we needed the extra info for the future. I think it was when we were discussing ExtInstall updates.

johnsfine · Post by **johnsfine** » Wed Apr 21, 2004 12:28 pm

I was interrupted while typing my previous (a common problem) so it relates to things said earlier.

Now trying to comment on the related issue in Mark's post:

I think the KeyMove entry (what's the right thing to call that?) is the right place to keep the association between a KeyMove and a device upgrade. I think that is easier and cleaner than keeping some backup copy of the pasted upgrade itself.

There are several features we may want later that depend on knowing that a KeyMove is logically part of a device upgrade. The most important is what to do about KeyMoves when the upgrade is deleted, but there are others. They all are "ahead of ourselves" as Mark said and more "wish list" than "plan". But structuring the KeyMove information to either have that field or be able to add it later is something we should think through now.

johnsfine · Post by **johnsfine** » Wed Apr 21, 2004 12:41 pm

Nils_Ekberg wrote:
1) Save all keymoves to the file not just the ones with notes.
2) When a keymove is manually entered flag it as ADDED.
3) When a delete of the upgrade is done delete the keymoves that are not flagged as ADDED.
4) When an upgrade is replaced do the same as 3.
5) for 3 & 4 a confirmation prompt should occur just incase the user does not really want to delete the keymoves.
6) Prompt for deletion of the ADDED keymoves that are associated with an upgrade that is being deleted.

That's roughly what I had in mind (and I still think it's the right basic approach). But an "ADDED" flag (actually its lack) doesn't convey enough information.

I want a field on what you'd call the non ADDED KeyMoves that indicates exactly which upgraded they arrived in. The "ADDED" KeyMoves would be the ones with that field missing or empty (howver you want to represent that).

Remember there are many ways a KeyMove may be associated with an upgrade:

1) A KeyMove in any device mode may depend on an upgrade. We might want some optional confirm/delete logic for those, but they aren't the kind I was talking about, espically if they were "ADDED".

2) A KeyMove may be "part of" an upgrade and depend on it, as occurs when the device type map excludes the desired key.

3) A KeyMove may be "part of" an upgrade and not use that upgrade's setup code, (external functions in RM) usually because some other setup code is the cheaper (or only) way to get less common subdevices of a device.

4) A KeyMove may be in the device mode of an upgrade but not part of it. Typically an input select or vol command of some other device that is related only through the user's behavior (which devices are used together) rather than by anything that belongs in an upgrade.

e34m5 · Post by **e34m5** » Wed Apr 21, 2004 1:00 pm

Man...this gave me a headache. When you guys figure it out just let me know how you want to write out the info..

Phew...

Nils_Ekberg · Post by **Nils_Ekberg** » Wed Apr 21, 2004 3:23 pm

We may be able to take baby steps with this and start with the ability to delete keymoves if they were part of the original upgrade due to button mapping. I think these are pretty obvious since they are for the same device.

We could then look at the other keymoves John outlined which I call either ADDED keymoves or external function keymoves (from RM).

The big thing we need to work out now is how to flag keymoves by type so we can manage them.

Second thing is what do we do with upgrades and keymoves that are already in the image when this feature is added.

Mark Pierson · Post by **Mark Pierson** » Thu Apr 22, 2004 5:46 am

If the IR file format is going to use .ini style conventions, I would recommend that instead of having a [Key Moves] section, each key move or macro have its own section, i.e. [<BoundDevice>:<BoundKey>]. For example, a typical key move entry might look like:

[TV:TV/VCR]
Notes=Toggles input from ANT to LINE
Upgrade=TV/1234

As new features are added, additional keys can be created to store the pertinent details.

Just my $.02.

Nils_Ekberg · Post by **Nils_Ekberg** » Thu Apr 22, 2004 10:53 am

I do like the format suggestion.

If we are thinking of making format changes we need to decide soon since they could impact the changes needed for ExtInstall, IRtoWAV, etc. Unless what is done with them is to just ignore the notes.

Hopefully others will chime in

johnsfine · Post by **johnsfine** » Thu Apr 22, 2004 11:26 am

I have no net opinion on whether or not each KeyMove should have its own section (There are things I like about that and things I dislike).

It won't make a big difference for ExtInstall. I hope it won't make any difference for IRtoWAV. IRtoWAV just reads the eeprom image, so it need not know how to write and it should ignore everything other than image itself.

I've been having computer problem both at home and at the office, which is my current reason for not doing extinstall. My previous reason was that I never found my source code (every time I was at one computer that didn't have it, I concluded it was at one of my other computers. It took a while to realize it isn't any of those places). I assume a good enough version of the source is on JP1-KM, but I haven't checked there lately either.

Nils_Ekberg · Post by **Nils_Ekberg** » Thu Apr 22, 2004 12:07 pm

The more I think about it the more I think it may be worthwhile to stick with the entry format that is now in ver 5. The functions and the routine to read them took a long time to get stabalized and I am not sure what the gain would be other than ease of readability with a manual edit. Although I like the proposed format I think it may lead to more errors and complexity in reading the file.

If we keep it at a section level like keymove, general, macros we can always add additional sections.

Just my $.02