RMIR To-do List and Wish List

[gfb107]

This is where I'm going to keep track of the to-do list for RM (in KM mode and in IR mode).
I will keep the to-do list up to date in this first post. As items are implemented, I'll move them to the implemented list under the implementing release.

The list is in no particular order. In addition, this thread can also be used as a place for users to make suggestions or requests. Those that are accepted will be added to the to-do list.

The RM To-Do List (in no particular order)

• KM Mode
  • WAV upgrade file import/export
• IR Mode
  • Fav/Scan
  • Set remote clock on upload
  • TimedMacros
  • Allow disassociating keymoves and protocol code from device upgrades
  • JP1 Serial cable communication for Windows and Linux (32-bit and 64-bit)
  • RDF v4
  • WAV file generation
  • Start-up in IR mode, and allow switching into KM mode for loading/creating/editing device upgrades.
  • Readme updates
  • ExtInstall, or equivalent
  • File -> New
  • Upgrade overflow
  • Use FixedData to select remote when multiple RDFs match the signature
  • MultiMacros
  • Internal/Native DSM (macro encoded)
  • Move DSMs to Macro tab
  • DecodeIR updates
• Tutorial (JP1 - Just How Easy Is It - using just RM)

The RM Implemented List (by release, descending)

• Version 1.93
  • KM Mode
    • Improve change detection/tracking
  • IR Mode
    • Raw Download
• Version 1.91
  • KM Mode
    • Show bytes used by device upgrades, keymoves, and protocol code
    • Fix handling of required vs. not required protocol code
    • Complete Manual Settings support
    • Copy'n'paste on buttons tab
  • IR Mode
    • JP1 Parallel cable support for 64-bit Linux
    • JP1.2/3 Serial/USB cable support for 64-bit Linux
    • Fix key style keymove support for remotes that use it.
    • Verify writes

[Capn Trips]

For RMIR:

Enable Extinstall operation. (If it's there, I cannot find it.)

[gfb107]

Enable Extinstall operation.

Accepted. There is discussion about changing the extender RDFs to include everything needed to install an extender by simply doing a File -> New. So by the time I implement this in RM it may work very differently than it does in IR today.

[The Robman]

I would like the data in RM to be more robust. For example, I may open an upgrade that uses a regular protocol and I may decide to switch it to the combo version so I can add more functions, but doing so will often zero out all of the function codes, with no way to recover them. This is one of the main reasons that I always develop a new upgrade using KM and then convert it to RM at the last moment.

I would also like the Buttons tab to be cut and paste-able, just like most of the other tabs are.

[gfb107]

I would like the data in RM to be more robust. For example, I may open an upgrade that uses a regular protocol and I may decide to switch it to the combo version so I can add more functions, but doing so will often zero out all of the function codes, with no way to recover them. This is one of the main reasons that I always develop a new upgrade using KM and then convert it to RM at the last moment.

RM tries to preserve device parameters by name when you do this, and it tries to preserve the OBC for functions. If that isn't working (it's not something I ever do, so it may be broken), that's a bug. If you could give me specific directions for reproducing it, I'm sure it wouldn't be too hard to fix.

I would also like the Buttons tab to be cut and paste-able, just like most of the other tabs are.

Interesting. You want to be able to paste in a column of function names and have RM find the matching function and assign it? That also shouldn't be too hard to do.
I'm just curious, where are you copying from?

[xnappo]

I think that the way that keymoves work in RM-IR is a little confusing. It is really cool that the 'upgrades' assign to keymoves automatically - but I think I would like:

1. A button on the keymoves tab to 'show keymoves from upgrades'
2. When adding a keymove on the keymoves tab, have one of the options be 'keymove from upgrade' (so you could select the function from an upgrade - definitely something only RM-IR can do).

Also - I would like to have the 'key' type of keymove added to RM-IR.

Thanks for your consideration!

xnappo

[The Robman]

RM tries to preserve device parameters by name when you do this, and it tries to preserve the OBC for functions. If that isn't working (it's not something I ever do, so it may be broken), that's a bug. If you could give me specific directions for reproducing it, I'm sure it wouldn't be too hard to fix.

Next time I get bit by this I'll post exactly what I was doing at the time. I think the main difference between KM and RM here is that KM will always preserve the first column of data in the Functions sheet, regardless of whether that data is in EFC or OBC format. RM doesn't have a fixed column, so you don't know what you're supposed to keep. Sometimes, holding onto the OBCs will be the right decision, but sometimes you should be holding onto the HEX or the EFCs. Maybe what's needed is something that lets you designate which column to preserve when you change the protocol. I'm not sure what the best UI would be for this, maybe a right-click option? And if you haven't locked one of the columns, maybe when you change protocols on the main tab, and there's data in the Functions tab, you could get a pop-up asking which column to keep. Maybe you should just keep whichever column gets dragged to the left besides the function names. I'm not sold on a particular UI solution, but I definitely would like the ability to specify which column should be kept.

The same problem exists on the main tab where if you change protocols, the device code data that you've entered might disappear. This happens when the boxes have different labels. I'd like RM to keep mirror images of the data behind the scenes in fields with generic names (like box1, box2, etc), so that if I switch from a protocol that has a device1 and a device2 to one that has a device and a sub-device, the codes entered don't disappear.

Interesting. You want to be able to paste in a column of function names and have RM find the matching function and assign it? That also shouldn't be too hard to do.
I'm just curious, where are you copying from?

I would be copying from RM itself. The other day I think I was trying to change a protocol from "manual settings" to one of the pre-formatted protocols, and everytime I made the switch I lost everything, so what I wanted to do was copy all of the EFCs and button assignments from RM over to a spreadsheet, so that when the correct protocol was selected I could just cut and paste everything back in.

[Barf]

Ideally, I would like to see RM not just like an interactive program, but as a Java API consisting of classes that can be used to read/create/manipulate RDFs, IRs, RMIRs etc. I have done some experimenting in that direction, with some, limited, success, but it is clear that the classes in RemoteMaster.jar were not written to be called outside of RM. Tonto does this quite good IMHO.

Yes, that is vague...

[johnsfine]

Sometimes, holding onto the OBCs will be the right decision, but sometimes you should be holding onto the HEX or the EFCs.

I think the design assumed OBCs were correctly defined by protocols.ini for both the protocol you switch from and the one you switch to. So for protocols defined in protocols.ini wanting to preserve HEX or EFC should be a very obscure case. Am I missing something? (other than manual settings, see below).

Maybe what's needed is something that lets you designate which column to preserve when you change the protocol. I'm not sure what the best UI would be for this, maybe a right-click option?

I think that adds more complexity for the user than the issue justifies. There is always the fall back of copy/paste columns in the functions sheet. (If that doesn't work right and/or breaks the buttons sheet in some way, that is an item that should be corrected).

But when switching to/from manual settings, I think the OBC must be assumed unsound. I think it would be better for RM to unconditionally preserve hex cmd instead of OBC when switching to/from manual settings. Of course that isn't always correct either. Sometimes the user would need to switch twice: first to a protocol with compatible hex commands (correct hex command to OBC translation rule) then to the protocol he really wants. Or sometimes column copy/paste would be needed.

[The Robman]

If I can't tell RM what to preserve, I'm probably going to keep using KM to develop upgrades where I always know that the column to the right of the function names (regardless of whether that column holds OBCs or EFCs) is the one to preserve.

I've just been bitten too many times in RM where I change one little thing and end up losing all my data.

I agree this is a problem that I'm more likely to encounter than the regular Joe JP1 user because of the nature of the kind of programming that I do, but if we're ever going to consider RM to be a complete replacement for KM, it would need to be addressed. But I guess as long as KM is still there, it's not an urgent issue.

[gfb107]

Ideally, I would like to see RM not just like an interactive program, but as a Java API consisting of classes that can be used to read/create/manipulate RDFs, IRs, RMIRs etc. I have done some experimenting in that direction, with some, limited, success, but it is clear that the classes in RemoteMaster.jar were not written to be called outside of RM.

Considering that there's been only 2 developers to ever commit any changes (in the 6 years the project has existed), I'd say there's virtually no demand for that.

[gfb107]

I've just been bitten too many times in RM where I change one little thing and end up losing all my data.

This really bothers me. You've encountered a problem so many times it has influenced the way you use (or won't use) RM, and yet this is the first time I remember it being mentioned. Maybe you reported it at a time when I wasn't monitoring the forums.

Please, everyone, if you run into a problem in RM, report it so something can be done about it. If I don't know about it, it definitely won't get fixed. I can't make any promises about how quickly I'll fix reported issues, but I can guarantee that those I don't know about will not get fixed.

If you don't see a response from me about an issue you've raised, bump it up again in a week or so. I may have just missed it.

There's a bug/feature tracking system at sourceforge we could use for this kind of stuff, but most people seem to prefer using these forums

[johnsfine]

Considering that there's been only 2 developers to ever commit any changes

Thanks for saying "2" instead of "approximately one" which is closer to the truth.

I keep intending to get back to making RM enhancements, but it never seems to happen. Last time I tried to even get ready to do so, I discovered my old setup for accessing CVS at sourceforge no longer works. I didn't want to bother you for help fixing it until I become more confident I can actually contribute something.

But if someone else want to start contributing enhancements to RM, you shouldn't discourage it.

[Barf]

Ideally, I would like to see RM not just like an interactive program, but as a Java API consisting of classes that can be used to read/create/manipulate RDFs, IRs, RMIRs etc. I have done some experimenting in that direction, with some, limited, success, but it is clear that the classes in RemoteMaster.jar were not written to be called outside of RM.

Considering that there's been only 2 developers to ever commit any changes (in the 6 years the project has existed), I'd say there's virtually no demand for that.

Ok, I did not get my message through, . Next attempt:

Consider that you want to write a (Java-)program that generates/reads/manipulates jp1-objects (device updates, RDFs, IR images). Like generating device upgrades (or flashable images), e.g. from other sources (CCF files?), or extracting information (what buttons are available?), or generating documentation for a setup. (I have such stuff in the pipeline...) Most importantly, this is interesting for another, wider group than the number of people ready and willing to commit fixes to RM sources.

[The Robman]

This really bothers me. You've encountered a problem so many times it has influenced the way you use (or won't use) RM, and yet this is the first time I remember it being mentioned. Maybe you reported it at a time when I wasn't monitoring the forums.

I have mentioned it before and you replied that it was due to the fact that if the new protocol uses different names for the entities than the previous protocol, the data is lost. Granted I didn't pursue it with you, but I did raise it. You seemed to be saying that RM was working the way you wanted it to, so I didn't bother trying to convince you to change it.