RouteConverter and Mac OS X

[hvdwolf]

Coming back on this: Is there anything I can do to help you with this? Things I could try on either Linux or MacOSX?

My plan is to switch to polling from the Java-side to the Browser-side if the other way is impossible due to the same origin policy. I'd need some testers once this is implemented.

Just let me know when you are finished. I'm currently on holiday, so I'm not always sure when I have a internet connection.

Where you could help is a working ZIP approach. I've lost the overview on what has to be done. But I've analyzed that 85% of the Mac users downloaded the ZIP if there is a JAR. What is the structure of a good ZIP? Something I could try to reproduce with Maven...

The structure of a good zip, is simply the application (or jar) inside the zip.

I did have a very simple application structure
see below

Code:

RouteConverter64.app/
RouteConverter64.app/Contents/
RouteConverter64.app/Contents/Info.plist
RouteConverter64.app/Contents/MacOS/
RouteConverter64.app/Contents/MacOS/routeconverter
RouteConverter64.app/Contents/MacOS/RouteConverterPrereleaseMac64.jar
RouteConverter64.app/Contents/Resources/
RouteConverter64.app/Contents/Resources/RouteConverter.icns

You can find the zip with the application in it here.
The application is simply started by a shell script. What this application lacks is a test application that checks for the correct java version. I don't know how easy or difficult it is to write a simple jar to check for the java version. This version check jar checks the java version: If OK start the jar, If wrong version report it to the user and exit.

[routeconverter]

What this application lacks is a test application that checks for the correct java version. I don't know how easy or difficult it is to write a simple jar to check for the java version. This version check jar checks the java version: If OK start the jar, If wrong version report it to the user and exit.

So you'd like to do something like this inside the script?

RESULT_CODE='java -jar VersionCheck.jar'

where the result code is 0 for OK and something like 10 if it failed (plus a dialog for the user). And it had to be compiled against Java 1.1 like the applet on the download page to be useful. I guess that's half an hour of effort plus some testing...

And as a side note: the prereleases have a Java version check for a version greater than 1.6.0_13 since there is a bug inside the XML parser in previous versions. But that code is compiled against Java 6...

[hvdwolf]

What this application lacks is a test application that checks for the correct java version. I don't know how easy or difficult it is to write a simple jar to check for the java version. This version check jar checks the java version: If OK start the jar, If wrong version report it to the user and exit.

So you'd like to do something like this inside the script?

RESULT_CODE='java -jar VersionCheck.jar'

where the result code is 0 for OK and something like 10 if it failed (plus a dialog for the user). And it had to be compiled against Java 1.1 like the applet on the download page to be useful. I guess that's half an hour of effort plus some testing...

That is exactly what I mean. To stay compliant with linux/unix/BSD (macosx) error checking it should be 1 instead of 10 in case of an incorrect version.

And as a side note: the prereleases have a Java version check for a version greater than 1.6.0_13 since there is a bug inside the XML parser in previous versions. But that code is compiled against Java 6...

I made the upgrade to Snow Leopard as well so I can't test anymore against lower than java 6. Same for Ubuntu 10.04, that only comes with java 6.x as well.
However, if the error code from the prerelease could be "catched" as well that would be just as handy. I don't know however how I should "catch" the error code from a java command, but I will do some googling.

[routeconverter]

RESULT_CODE='java -jar VersionCheck.jar'

That is exactly what I mean. To stay compliant with linux/unix/BSD (macosx) error checking it should be 1 instead of 10 in case of an incorrect version.

Ok, please try http://www.routeconverter.de/download/Java6Check.jar and tell me, if it helps.

[hvdwolf]

Ok, please try http://www.routeconverter.de/download/Java6Check.jar and tell me, if it helps.

Currently I'm still on holiday with only my own macbook with java 1.6+ on it. As soon as I'm home (max. 1 week) with other options available, I will try.

[hvdwolf]

And as a side note: the prereleases have a Java version check for a version greater than 1.6.0_13 since there is a bug inside the XML parser in previous versions. But that code is compiled against Java 6...

I did not read this careful enough. Does that mean the prerelease gives an error message when the java version is too low? <1.6 ?
Or does it give an error/warning message on java versions between 1.6.0 and 1.6.0_13?

Also: Is it then necessary to use the Java6Check.jar?

[routeconverter]

I did not read this careful enough. Does that mean the prerelease gives an error message when the java version is too low? <1.6 ?
Or does it give an error/warning message on java versions between 1.6.0 and 1.6.0_13?

It warns if the version is below 1.6.0_14.

Also: Is it then necessary to use the Java6Check.jar?

Yes, because that checks for older Java versions before 1.6 that cannot even execute RouteConverter since it's now compiled for Java 1.6.

[routeconverter]

Of course - that's related to problem with the unreachable port. Something is blocking the web browser (I guess it's a Web Kit-based component) to direct AJAX-calls to the port from the RouteConverter process.

I found out, what the for this behaviour is: the error is NS_ERROR_DOM_BAD_URI and the cause is the same origin policy that changed between XUL Runner 1.8 and 1.9 as explained here.

Hello Mac OS X and Linux users,

I think I found a solution to the callback problem:

• the dialog "check your firewall settings" is gone
  
• instead RouteConverter switches to polling instead of event listening (the log says something like 'setCallbackListenerPort(-1)')
  
• i.e. the JavaScript side does not execute AJAX requests to notify the Java side, but it collects the events and the Java side is polling them
  

From a software engineering perspective this isn't a good solution but it seems to work on my box. You should be able to select positions in the position list and drag them on the map. And the Tools/Insert positions... dialog should be working now.

Please check the latest prerelease and report!

[asp]

Seems to work, thanks for the update :-)
There's no dialog "check your firewall settings" anymore and I can drag positions.

I noticed one thing: moving the position works, but the red flag in the old position stays in some cases (the position itself, the black-white-colored circle, disappears). When the position has been created (i. e., never moved before), the first time it is moved the flag disappears correctly. The second time the old flag stays.
(If I move a flag that's left over from a dragging before, sometimes it is really moved, sometimes it is duplicated. I see no pattern there.)

[routeconverter]

If I move a flag that's left over from a dragging before, sometimes it is really moved, sometimes it is duplicated. I see no pattern there.

Thank you for the report. Please try to find the pattern behind that bug. Do the coordinates of the dragged position change in the position list if the flag is duplicated?