JP1 Remotes

mathdon wrote:

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.

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.

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.

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.

Barf wrote: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.

Barf wrote: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.

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.

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?

Barf wrote: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.

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

I will merge your rmProtocols.xml into IrpProtocols.xml for the final version 1.2.7, to be published today or tomorrow.

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.