RM-IR is too large under linux

[jurgyman]

Really happy to see RM-IR version with integrated IR upload ability!
and it works under linux too!

one problem thats keeping me from using it however...
If you click edit device and have the classic remotemaster window pop-up,
its too large under linux to see the bottom of the window, making it impossible for me to SAVE it!

[mathdon]

Have you tried RMIR v2.02 Beta? I have tried to cure this problem in that beta version, so if you have not tried it, please do so and report here whether or not that is OK for you. See this thread for info about this version and a link to the file.

[jurgyman]

unfortunately it was 2.02beta under linux/fluxbox that causes the issue...
my java version is: 1.6.0_22-b22
happens when I do EDIT....
not when I separately click rm icon

[mathdon]

unfortunately it was 2.02beta under linux/fluxbox that causes the issue...
my java version is: 1.6.0_22-b22
happens when I do EDIT....
not when I separately click rm icon

Could you post a screenshot, or better still, two screenshots with one showing RM directly and the other showing the result of doing EDIT? They run the same code, so I can't at present see why the size should differ. I would like to resolve this issue and there may be a clue in the appearance of the two screens. You also seem to be suggesting that the problem wasn't present in earlier versions. Is this right?

[eferz]

Could you post a screenshot, or better still, two screenshots with one showing RM directly and the other showing the result of doing EDIT? They run the same code, so I can't at present see why the size should differ. I would like to resolve this issue and there may be a clue in the appearance of the two screens. You also seem to be suggesting that the problem wasn't present in earlier versions. Is this right?

I just tried it on my Linux VM and I see something similar to what jurgyman is referring. But, its not as bad as he claims it to be. The "Device Upgrade Editor" from RMIR will try and open the window as big as it can to show the protocol notes. But, on my screen it doesn't ever go beyond the borders. Even if it did, one could click on Maximize for the window to show the the buttons on the bottom. Where as, "Remote Master" window does not have any notes and opens up fairly small by comparison.

• This is editing from RMIR
• This is opening up directly from RM

It could be the RemoteMaster.properties file has corrupt data in which case it could be deleted. Either RM or RMIR will recreate the file upon startup. Otherwise, his Xwindow server is acting goofy.

[mathdon]

Thanks eferz, it is very helpful to know that it is the Protocol Notes section that is causing the problem, not the main upgrade section. It is a pity that jurgyman did not respond to show the situation as he is encountering it. I find it disappointing, to say the least, when someone raises a problem but then doesn't follow it up when further information is asked for to help resolve it.

[eferz]

Thanks eferz, it is very helpful to know that it is the Protocol Notes section that is causing the problem, not the main upgrade section. It is a pity that jurgyman did not respond to show the situation as he is encountering it. I find it disappointing, to say the least, when someone raises a problem but then doesn't follow it up when further information is asked for to help resolve it.

You're welcome. Glad to help. It could be he realized the folly of the problem while gathering the information. So, it is possible that he hasn't responded due to pride or embarrassment

[agpccosta]

Same bug here as jurgyman, & deleting RemoteMaster.properties then restarting doesn't correct the oversized window, using .RemoteMasterv2.02 Beta.

Debian box, Java is 'openjdk-6', Version: 6b24-1.11.1-6

(User kludge to make window fit: 'Alt-space', then 'x', to maximize window.)

[Barf]

Java is 'openjdk-6', Version: 6b24-1.11.1-6

Have you tried with Sun's/Oracle's JDK?

[Barf]

Bug confirmed.

As I suspected, Openjdk and Sun's/Oracles JDK behaves differently: the first opens full-height, for me on my second screen, while the latter seems to "inherit" the coordinates of the parent window as much as possible. However, the underlying problem is this: Started as remotemaster and started as rmir, the program maintains two separate set of coordinates for the respective windows. From the properties file:

Code: Select all

RMBounds=949,496,948,669
KMBounds=391,226,944,618

However, when the child RM window is launched, it appears to be started without coordinates, giving the JVM freedom to do whatever it sees fit, explaing the different behaviors of different JVMs -- at least I think this is the interpretation. Starting an RM child through File -> New works fine though (new KeyMapMaster( properties ) line 682 in RemoteMaster.jave).

TODO: have the child RM frame fired up with the coordinates (KMBounds ) of the properties, AND save those on the ending of the frame.

[Barf]

Here is a/the fix. And here is RemoteMaster.jar if anyone wants to test without compiling (just replace RemoteMaster.jar in an existing installation.) Created from the current SVN source from today.

Code: Select all

Index: km/com/hifiremote/jp1/DeviceUpgradeEditor.java
===================================================================
--- km/com/hifiremote/jp1/DeviceUpgradeEditor.java      (revision 1113)
+++ km/com/hifiremote/jp1/DeviceUpgradeEditor.java      (working copy)
@@ -2,6 +2,7 @@
 
 import java.awt.BorderLayout;
 import java.awt.Frame;
+import java.awt.Rectangle;
 import java.awt.event.ActionEvent;
 import java.awt.event.ActionListener;
 import java.awt.event.WindowAdapter;
@@ -11,6 +12,7 @@
 import java.text.DateFormat;
 import java.util.Collection;
 import java.util.Date;
+import java.util.StringTokenizer;
 
 import javax.swing.BorderFactory;
 import javax.swing.Box;
@@ -126,9 +128,24 @@
     saveAsButton.addActionListener( this );
     okButton.addActionListener( this );
     cancelButton.addActionListener( this );
-    pack();
+
+    String temp = JP1Frame.properties.getProperty( "KMBounds" );
+    if ( temp != null )
+    {
+      Rectangle bounds = new Rectangle();
+      StringTokenizer st = new StringTokenizer( temp, "," );
+      bounds.x = Integer.parseInt( st.nextToken() );
+      bounds.y = Integer.parseInt( st.nextToken() );
+      bounds.width = Integer.parseInt( st.nextToken() );
+      bounds.height = Integer.parseInt( st.nextToken() );
+      setBounds( bounds );
+    }
+    else
+    {
+      pack();
+      setLocationRelativeTo( owner );
+    }
     editorPanel.setAltPIDReason();
-    setLocationRelativeTo( owner );
     setVisible( true );
   }
 
@@ -165,6 +182,8 @@
         }
         setVisible( false );
         dispose();
+        Rectangle rect = this.getBounds();
+        JP1Frame.properties.setProperty("KMBounds", "" + rect.x + ',' + rect.y + ',' + rect.width + ',' + rect.height );
         editorPanel.releasePanels();
         if ( panel instanceof GeneralPanel )
         {

[mathdon]

Barf, this fix does not seem to have been uploaded to SourceForge. If you want it to be in the next beta version of RM/RMIR, please upload it. I have no idea what to do with it in the form you have posted above.

[Barf]

Please let me explain.

My understanding of the inner workings of RM is limited. While I am reasonably confident that the patch is "sane", and I have done a reasonable testing myself, it still cannot quite be ruled out that there are side effects, "new bugs". Or that someone just does not "like" it and the changed behavior, for justified or not justified reasons.

Up until now, the jar file has been downloaded exactly twice, resulting in exactly 0 test reports.

So what can an experienced RM used do? Download the jar, and just try out the things you normally do, and check that nothing seems broken. In particular are the windows (RM and RMIR) properly positioned, and are their positions saved between invocations? It is less important to check that the original problem has been fixed (I am confident here), more important are any new bugs or annoyances.

I have experienced more than once that I ask for feedback on an action, wait a long time for responses but no-one responds, then the action is performed, and all hell breaks loose.

If the community (in particular jurgyman and agpccosta) does not care enough to test a proposed solution, it is hard to believe that the fix is needed...

I will be happy to check in the fix after positive feedback and testing has been received.

@Graham: The day you ask me what to do with a diff-file, I'll tell you.