RM/RMIR v2.10 available

[Barf]

From another thread

I have now uploaded RMIR with Girr export to the SVN. As with Girr import, it is in RM on the File menu and in RMIR on the Device Upgrade tab as a button and also in the popup menu. I have found it much easier to test using RMIR, as there are .rmir files with many device upgrades rather than loading one at a time into RM.

The rmProtocols.xml file that is included has entries of several types:

• (a) Correction of errors that are nothing to do with Girr export but discovered during testing. These include corrections of all uei-executor entries that have parameters such as F>63, as I had misunderstood the use of such parameters when creating those entries in the first place.
  
  (b) Additional prefer-over entries to ensure that Girr export uses the most appropriate protocol, such as NEC1 rather than NEC-f16 for an NEC1 signal.
  
  (c) Tweaks to ensure the invertability of certain parameter expressions, such as changing (OEM1<<8)+OEM2 to (OEM1<<8)+OEM2:8 as the former cannot be inverted without knowing that OEM2 does not have more than 8 bits.

I have also made a change to the IRP of RC6-6-20 to change T from an automatic parameter to a specifiable one, as the 0020:2 executor has T as a device parameter. The notes say that this is commonly used by Sky and Sky+ remotes and the executor notes say that Sky does not toggle T.

I have tested the Girr exporter on around 20 device updates. All of them either succeeded or the exporter gave up gracefully! Congratulations Graham!!

I have some fixes for getting misc. information on the right places, DeviceUpgradeExporter.java.

Also, I would propose a Girr export on full RMIR configuration, consisting of a RemoteSet containing one Remote per DeviceUpgrade.

[Barf]

ICT (the save format for IrScope) has a certain usage in this community. Using the IrScrutinizer class org.harctoolbox.irscrutinizer.importer.IctImporter and the Girr importer already implemented by Graham, it would be a fairly simple task to implement am ICT importer for RM, similar in use to the Girr importer. More in detail, the function IctImporter(File) delivers a Collection<Command>, which can be essentially just fed into the Girr importer.

WHADDYASAY?

[mathdon]

I suspect the idea of exporting a device upgrade as a Girr file seems an arcane irrelevance to many users, but it is not. It in fact enables something that to me, at least, seems rather magical. Exporting a device upgrade as a Girr file and then importing that file into IrScrutinizer enables the IR signals of the upgrade to be generated without the involvement of any remote control, using any IR sending hardware supported by IrScrutinizer. Indeed, by using the appropriate GlobalCache sender the connection between the PC and the IR sender can be with WiFi, enabling the sender to be distant from the PC. No remote control involved, no protocol executor, just magic .

[mathdon]

I have some fixes for getting misc. information on the right places, DeviceUpgradeExporter.java.

I have incorporated this, but it assumed that upgrade.getFile() was non-null. This is only so if exporting from a file loaded into RM. It is null if exporting an upgrade from RMIR, or one created in RM without saving it. I have fixed this, hope you are happy with the fix.

Also, from the IrScrutinizer thread:

I have to say that it is a bit disappointing if import of the Yamaha-fiile "semi fails", in the sense of offering the (for us useless) 005A. If it takes some time -- who cares as long as it is not minutes? A similar remark applies for the Philips VCR.

I have uploaded to the SVN a fix for this. It is a substantial rewrite of the dialog for selecting an executor when converting a set of learned signals to a device upgrade, or importing a Girr file as one. I think it is a substantial improvement. Let me know what you think.

[Barf]

Some quick feedback:

... It is null if exporting an upgrade from RMIR, or one created in RM without saving it. I have fixed this, hope you are happy with the fix.

OK. But I think the program should call itself "RemoteMaster", not the awkward "RM/RMIR".

BTW, just recently I fixed a bug in Girr that prevented creation data to be included in the generated file.

I have to say that it is a bit disappointing if import of the Yamaha-fiile "semi fails", in the sense of offering the (for us useless) 005A. If it takes some time -- who cares as long as it is not minutes? A similar remark applies for the Philips VCR.

I have uploaded to the SVN a fix for this. It is a substantial rewrite of the dialog for selecting an executor when converting a set of learned signals to a device upgrade, or importing a Girr file as one. I think it is a substantial improvement. Let me know what you think.

Yes, much better. But it still fails on the philips_vr1100.girr (RC5, device=5, OBC/F both <= 63 and > 63)) if I select the first (RC5) executor.

Also, for Girr import I would suggest taking Remote.getName() into Description, and filling in Notes with something like "Imported from Girr file filename".

When starting a device upgrade editor from RMIR, there is no way to invoke a Girr export from that DU editor (it lacks the File pulldown menu from the standalone DU editor).

[mathdon]

OK. But I think the program should call itself "RemoteMaster", not the awkward "RM/RMIR".

Fine, I will make that change.

Yes, much better. But it still fails on the philips_vr1100.girr (RC5, device=5, OBC/F both <= 63 and > 63)) if I select the first (RC5) executor.

That is one of those things that worked until I changed something else and did not retest. Fixed now, but not yet in SVN.

When starting a device upgrade editor from RMIR, there is no way to invoke a Girr export from that DU editor (it lacks the File pulldown menu from the standalone DU editor).

I don't understand this, there is an Export Girr button next to the Import Girr button, and it is also on the right-click pop-up menu. Or do I misunderstand the situation you are referring to?

On ICT import, I have now implemented that, but you will have to give me an official jar file of the relevant classes that I have extracted from IrScrutinizer.

By adding Girr to the list of supported files for RMIR, you have given it a similar status to KM .txt files, a format not native to RMIR that can be imported. I think this is preferable to the special status I had given it in having a specific Import Girr button and/or menu item, so I am getting rid of those buttons and menu items and instead adding Girr to the file types that can be loaded through the various Open or Load buttons and menu types. Ict will be treated similarly. Probably Export Girr should also be incorporated into existing Save As facilities.

My desire for symmetry makes me want an Ict export facility to match the Ict import, but I cannot see an org.harctoolbox.irscrutinizer.exporter.IctExporter class. Is there an easy way of doing this?

[Barf]

When starting a device upgrade editor from RMIR, there is no way to invoke a Girr export from that DU editor (it lacks the File pulldown menu from the standalone DU editor).

I don't understand this, there is an Export Girr button next to the Import Girr button, and it is also on the right-click pop-up menu. Or do I misunderstand the situation you are referring to?

I meant the following: Start RMIR. Load a non-trivial remote configuration. Go to Devices pane. Double click a device. This pops up a "Device Editor". This has no Import or Export button, no pulldown menu "curtain", and no popup menu.

On ICT import, I have now implemented that, but you will have to give me an official jar file of the relevant classes that I have extracted from IrScrutinizer.

Turned out that it did not fit too well, and I think including the whole IrScrutinizer jar is not a good idea, so I made this file instead. It takes a Girr File to a RemoteSet.

By adding Girr to the list of supported files for RMIR, you have given it a similar status to KM .txt files, a format not native to RMIR that can be imported. I think this is preferable to the special status I had given it in having a specific Import Girr button and/or menu item, so I am getting rid of those buttons and menu items and instead adding Girr to the file types that can be loaded through the various Open or Load buttons and menu types. Ict will be treated similarly. Probably Export Girr should also be incorporated into existing Save As facilities.

I am not quite sure what you mean. The distinction between "Save" and "Export" is blurred. IMHO, a "save" should save with (almost) no loss of information, and restored by a corresponding "open" (or "load"). Otherwise it is "Export". Note that it is possible to beef up the Girr export (and import) to fulfil this, using the <applicationData application="jp1"> element; see my recent fix.

My desire for symmetry makes me want an Ict export facility to match the Ict import,

The ICT format was invented by Kevin for the IRScope. It is a very simple text format. The reason why I suggested an ICT importer is that in this community, there are quite a collection of captures in this format. I cannot really see the use of an ICT export -- importing in IRScope??

... but I cannot see an org.harctoolbox.irscrutinizer.exporter.IctExporter class.

This is the ICT exporter. In IrScrutinizer, all export formats but four (Girr, Text, Pronto Classic, Wave) are written in XSLT. The program generates a Girr "file" (technically a DOM, Document, in memory) with raw in "fat format", and applies the transformation to it, generating either text or another XML file.

[mathdon]

Just a quick reply to some of your points. I have not included the whole of IrScrutinizer, just 11 files packaged into a 20Kb jar file. I did eventually realize what you meant about Girr Export not being available when the Device Upgrade Editor is accessed from RMIR, and will fix that. I agree with your distinction between Save and Export, but I am not sure whether there is one between Load (or Open) and Import. You have enabled a girr file to be given as an argument to RemoteMaster when it is opened, which I see as implying that you are also happy with a Girr import being done through File > Open. I think that preferable to having a dedicated Import button or menu item.

[mathdon]

I hope that the version now in the SVN incorporates all your recent suggestions and necessary fixes. In addition there are the following changes:

(a) Import of Girr and Ict files can now be done from the File > Open menus of RMIR and RM. With RMIR it opens a new stand-alone instance of RM and imports to that. Correspondingly I have removed the Import Girr item from the RM File menu.

(b) On the Device Upgrade Editor opened from RMIR with the Edit or New buttons of the Devices tab, the Open button now supports import of Girr and Ict files and the new Export button supports exporting as Girr file.

(c) On the RMIR Devices tab the Import Girr and Export Girr buttons have been renamed simply as Import and Export, as I think Import Girr/Ict is too cumbersome. I had intended to delete these buttons in the belief that (b) made them redundant, but then I realized that Import from the Devices tab has a facility that is not present from DUE. This is the ability to append to an existing upgrade rather than create a new one. Perhaps this is unlikely to be of much use, but since the facility exists and there is no other access to it, I think it is worth retaining. It is inherited from the corresponding facility in converting learned signals to a device upgrade.

(d) I have tried to make the various messages that may appear be appropriate to their context, so messages in importing a Girr file should no longer refer to the selected learned signals. If you find any messages that are still inappropriate for their context, please let me know.

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? As for Ict export, you ask why I want to do it. Why do you do it in IrScrutinizer if you don't think there is any point in doing so? My sense of symmetry says that as it is a file format in current use, even if a very simple one, and it is supported for import then I would like it supported also for export if it is reasonably easily done. If it is not reasonably easy to do, then so be it.

[mathdon]

I found it easy to create my own exporter to .ict file format, so I have implemented this and it is now in the SVN.

[mathdon]

Also, I would propose a Girr export on full RMIR configuration, consisting of a RemoteSet containing one Remote per DeviceUpgrade.

Done. Now in SVN. Menu item File > Export remote as Girr file.

[mathdon]

Some minor general suggestions:

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.

2. Why? I see no point in this change.

3. Will do.

[mathdon]

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]

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.

[Barf]

I just tried it (compiled from SVN) and did not encounter anything unexpected (which was unexpected!! ) Good job.

I see that this one did not make it (end of page 1). Forgot, or there is a reason?

Here is a patch that sharpens the Auto assing function:

Code: Select all

Index: com/hifiremote/jp1/Function.java
===================================================================
--- com/hifiremote/jp1/Function.java    (revision 1700)
+++ com/hifiremote/jp1/Function.java    (working copy)
@@ -359,19 +359,30 @@
   } 
  
   private static String[][] substitutes = { 
-    {"key_", ""}, // Lirc 
+    {"_", ""},
+    {"key", ""}, // Lirc 
+    {"cmd", ""}, 
+    {"num", ""}, 
...

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.

PS. Sorry for the delay.