RouteConverter and Mac OS X

[hvdwolf]

They best way to debug would be if you'd started RouteConverter from an IDE like IntelliJ IDEA or Eclipse, put a breakpoint on ConvertPanel#saveFile()
and start the debugger.

Please see this new thread in the development sub-forum

[routeconverter]

Did you try my Java6Check jar on your machine?

[hvdwolf]

Did you try my Java6Check jar on your machine?

Yes, I did. But as mentioned I'm now on Snow Leopard and I don't have Java 1.5 anymore. So it works for me.
I have to ask a friend to test for me. He is back in the weekend and I hope he has time then to test for me.

---

They best way to debug would be if you'd started RouteConverter from an IDE like IntelliJ IDEA or Eclipse, put a breakpoint on ConvertPanel#saveFile()
and start the debugger.

I now did that according your directions and that works.

However, when started in debug mode from IntelliJ, the "-XstartOnFirstThread" is not given and RouteConverter starts without map. Than it functions perfectly allright: opening, saving, preferences. All work fine.

So I started the jar from the commandline also without the "-XstartOnFirstThread" option. Off course, the map isn't visible but the opening, saving and preferences work as they should. With the map loaded Routeconverter is hanging again.
You changed that to make it possible for Linux/MacOSX/BSD users to insert points.

Does this give some more info?

[routeconverter]

However, when started in debug mode from IntelliJ, the "-XstartOnFirstThread" is not given and RouteConverter starts without map. Than it functions perfectly allright: opening, saving, preferences. All work fine.

Ok, so it's really related to the SWT stuff.

You changed that to make it possible for Linux/MacOSX/BSD users to insert points.

What I've changed was that events are polled from the web browser. If you want to disable it, go to class BaseMapView around line 507 and comment out

if(!receivedCallback[0]) {
setCallbackListenerPort(-1);
initializeCallbackPoller();
}

This disables polling. Then edit the Debug configuration in IntelliJ to include -XstartOnFirstThread in 'VM parameters'. Now does this change the slow menu behaviour?

[routeconverter]

Did you try my Java6Check jar on your machine?

Yes, I did. But as mentioned I'm now on Snow Leopard and I don't have Java 1.5 anymore. So it works for me.

Sorry, I wasn't precise: did you integrate the Java6Check into your shell script? I'm planning to spend some time to get exactly your ZIP layout since a lot of Mac OS X users ask me how to use RouteConverter and I'm tired of explaining the -XStartOnFirstThread stuff

[hvdwolf]

Did you try my Java6Check jar on your machine?

Yes, I did. But as mentioned I'm now on Snow Leopard and I don't have Java 1.5 anymore. So it works for me.

Sorry, I wasn't precise: did you integrate the Java6Check into your shell script? I'm planning to spend some time to get exactly your ZIP layout since a lot of Mac OS X users ask me how to use RouteConverter and I'm tired of explaining the -XStartOnFirstThread stuff

Yes, I already did that. I built a mini-Applescript application that shows a graphical popup in case the java version is too low: see attached image.
the script itself is:

Code:

#!/bin/sh
BASEDIR=`dirname $0`
if `exec java -jar $BASEDIR/Java6Check.jar`; then
   # No error, java version >= 1.6.0_14
   echo "java version >= 1.6.0_14"
   exec java -XstartOnFirstThread -jar $BASEDIR/RouteConverterPrereleaseMac64.jar
else
   # java version < 1.6.0_14
   echo "java version < 1.6.0_14"
   open error_message.app
   exit 1
fi

the echo commands are not really neccessary but if a user whould open the application from the command line like "open RouteConverter64.app" it would also echo to terminal.
Note: I used the "RouteConverterPrereleaseMac64.jar" but that can be replaced off course. Both in the script and the application.

The structure of the Application now is (I removed unnecessary listing info):

Code:

ls -lR RouteConverter64.app
RouteConverter64.app/Contents:
       Info.plist
       MacOS
       Resources

RouteConverter64.app/Contents/MacOS:
        Java6Check.jar
        RouteConverterPrereleaseMac64.jar
        error_message.app
        routeconverter

RouteConverter64.app/Contents/Resources:
       RouteConverter.icns

1 - I wrote this simple applescript application (10 minutes work), but I don't know whether your application does shows a (graphical) error message of it's own as I can't test that right now. Does it?
If it does we can remove my error_message.app, which I really like to do. It's not nice to mix up a real Java application with an applescript application. To me it doesn't feel right.
If your Java6Check.jar shows it's own graphical message the script could change to:

Code:

#!/bin/sh
BASEDIR=`dirname $0`
if `exec java -jar $BASEDIR/Java6Check.jar`; then
   # No error, java version >= 1.6.0_14
   echo "java version >= 1.6.0_14"
   exec java -XstartOnFirstThread -jar $BASEDIR/RouteConverterPrereleaseMac64.jar
else
   # java version < 1.6.0_14
   echo "java version < 1.6.0_14"
   exit 1
fi

2 - I did not make a patch or something like that yet. It's easy to do but I like to know how you think about it, especially in case your jar show it's own message already.
3 - Just in case I added the error_message.app in a zip and the message itself

[hvdwolf]

What I've changed was that events are polled from the web browser. If you want to disable it, go to class BaseMapView around line 507 and comment out

if(!receivedCallback[0]) {
setCallbackListenerPort(-1);
initializeCallbackPoller();
}

This disables polling. Then edit the Debug configuration in IntelliJ to include -XstartOnFirstThread in 'VM parameters'. Now does this change the slow menu behaviour?

Yes, it certainly does. With the code enabled it is slow. With the code disabled it is normal speed. The "right-click insert" doesn't work anymore, but I assume that's exactly the point.

[routeconverter]

Yes, it certainly does. With the code enabled it is slow. With the code disabled it is normal speed. The "right-click insert" doesn't work anymore, but I assume that's exactly the point.

Good. Please go uncomment the code again and change line 429 from

Thread.sleep(100);

to

Thread.sleep(1000);

That increases the interval a request is sent to the webbrowser and might have an effect?

[hvdwolf]

Good. Please go uncomment the code again and change line 429 from

Thread.sleep(100);

to

Thread.sleep(1000);

That increases the interval a request is sent to the webbrowser and might have an effect?

Unfortunately it doesn't.
I found 3 other occurrences of that same kind of "Thread.sleep" statement. I also increased those 10X but that didn't make a difference.

[routeconverter]

That increases the interval a request is sent to the webbrowser and might have an effect?

Unfortunately it doesn't.

And what about 10000?

I found 3 other occurrences of that same kind of "Thread.sleep" statement. I also increased those 10X but that didn't make a difference.

Please don't touch them - they're for the route and marker updates.