1. This is not nice. Differently put, RM allows you without warning to assign stuff to system buttons, which is often confusing, as the quoted thread shows. It should either warn or refuse altogether, For this, the clean solution would be to have a SystemButtons property in the RDF, defaulting to Setup,Magic (for example).
2. Suggest rename the -admin option to -develop. (Just the command line option, no need to change the code.)
3. If a program ends unsuccessfully, it should (according to normal practice) return a non-zero status to the OS. So i suggest changing RemoteMaster.java line 6781 (in svn version 1703) from System.exit( 0 ) to System.exit( 1 ) (for example).
1. This is a matter for the RDF [Buttons] section. Button restrictions have extensive capabilities but most RDF writers don't bother using them. No new RDF syntax is needed, just use of what is already there.
Barf wrote:When a new device upgrade editor is started, it is filled in with a number of function names, without associated functions. I argue this is confusing for the novice, ugly and annoying for the rest of us.
Suggestion: remove it, replace with a function (on a button at the end, or in a pull-down menu), can be called "Templates" or "Dummy Functions". (Or just remove without replacement; personally I do not consider it very useful.)
I agree, it is done. I have removed the use of default function names, so the Functions tab of a new device upgrade will have an empty list. I have discovered that RM, but not RMIR, has a menu item Options > Function names that allows the user to choose between default names and an editable custom list that is preserved in the RemoteMaster.properties file. The default, of course, is now an empty list. I could add this option into RMIR, with the list common between RM and RMIR, if desired.
This change is now in the SVN, but not yet in an issued development build.
mathdon wrote:I agree, it is done. I have removed the use of default function names
On further consideration I felt that the user should have the option to use the previous default, so there is now an Options > Function names menu item in both RM and RMIR. It is slightly enhanced from that already existing in RM, now having three options: Empty (which is the new default), Default (which is the old default) and Custom (which is user-specified with the provided editor). This is now in the SVN.
Concerning Ict import, my preference is still to use the import classes of IrScrutinizer that I have extracted into the IctImporter.jar file of about 20Kb rather than use your new stand-alone IctImporter class, so this is what is in the SVN. Is there any great reason for me not do to do?
I think this is a bad solution. I spent a few hours making a RM-version and upload it, even adjusting the indentation to the style used in RM. Including a "home-made" jar is a bad idea for maintenance and further development. You must keep track of the exact version used to generate the mini jar. It is also very unfriendly to users who want to run a debugger, since the source is not there. Finally, creating a mini-jar is always an error prone thing. (The "transitive hull" of all functions therein...).
there is now an Options > Function names menu item in both RM and RMIR.
IMHO better would be an "button" for filling in the templates. New always creates an empty one, the use who wants to use the templates fires the button, others do not.
Barf wrote:I see that this one did not make it (end of page 1). Forgot, or there is a reason?
Mental confusion. I remembered having included this fix of yours for Auto assign and confused the two, so I thought I had done it. Now it really is done and in the SVN. Though since the new default is an empty function list for a new device upgrade, at your suggestion, there will be less standardization of function names and so Auto assign will be less effective.
I think this is a bad solution.
See my PM.
IMHO better would be an "button" for filling in the templates. New always creates an empty one, the user who wants to use the templates fires the button, others do not.
This seems inferior to what I have implemented. By default, New always creates an empty function list, users who want otherwise can use the old default or create their own custom list and such a choice is persistent. For such users, that is surely preferable to having to press a template button every time, and the user can create any custom template that is desired.
The SVN now contains my latest updates. This incorporates the current CI build of IrpTransmogrifier, and rmProtocols.xml is correspondingly updated. It now only contains a few remaining suggestions related to RC6-M-N protocols
RMIR v2.11 is now available. Please note that due to a recent change by SourceForge, the update checker in v2.10 and earlier no longer works and will report that you already have the latest version. The checker in v2.11 has been updated and will work correctly when there are future builds or versions.