RouteConverter and Mac OS X

[hvdwolf]

What do you mean? did you add new functionality to RouteConverter? I did not pay attention to that.

I thought the idea of all those properties is to make a Java application behave more like native Mac OS X applications.

With extra functionality I assumed you meant that you built something new into RouteConverter.
I did have a look at the mentioned settings and tried them as well. I really didn't notice any difference.
I tried them all again, one by one, and I really don't see any difference apart from the menu option which removes the menu.
I think MacOSX already applies all the settings automatically as the look&feel is already really native quartz.

[routeconverter]

I think MacOSX already applies all the settings automatically as the look&feel is already really native quartz.

Good, I'm removing them from the Constants class again.

Did you make any progress regarding the SWT-Webbrowser-polling-affects-menu problem?

[hvdwolf]

Did you make any progress regarding the SWT-Webbrowser-polling-affects-menu problem?

Sorry for being "away" for quite some time.

I have been trying with several times in the "Thread.sleep(xyz)" option. Slower times do influence the right-click behavior as it gets slower.
It does not influence the popup behavior. Higher sleep times make the popup as such appear slower. However, after that it simply keeps hanging, no matter the sleep time setting.
Could it have something to do with the window focus? Does this "Thread.sleep()" function maintain the focus within the main program/window, thereby stealing it from the popup? In this case the popup simply doesn't get the focus.
The entire file popup is populated apart from the files it should display (see attached image).
Is there something in the file handling on OSX that gets influenced by this timing setting?
When hovering with the mouse pointer over the red/orange/green window bulbs to close/minimize/maximize a window, you see the bulbs change getting a cross, minus sign and plus sign in the relevant bulb, but clicking it doesn't do anything.

BTW: I stumbled upon this article (http://nadeausoftware.com/node/90).

[routeconverter]

Sorry for being "away" for quite some time.

I'm glad you're here again!

Could it have something to do with the window focus? Does this "Thread.sleep()" function maintain the focus within the main program/window, thereby stealing it from the popup? In this case the popup simply doesn't get the focus.

I understand the connection between the Thread.sleep() and the file dialog as the following:

• in Mac OS X the first thread of a process does the event processing
  
• for Java, it seems the Apple engineers managed to connect this directly to the AWT-EventQueue thread which is the single Java thread used to update the user interface for pure Java apps -XstartOnFirstThread is not necessary
  
• for the browser, I'm using a library (DJNativeSwingSWT) that allows to embed Eclipse SWT components into Javas Swing UI framework
  
• Eclipse SWT consists of native code and Java wrappers (where Java Swing is pure Java)
  
• this means the event processing becomes a problem since events from the operating system must reach the native code components i.e. the browser and the pure Java Swing (via the native Java VM)
  
• -XstartOnFirstThread and the Java class chrriis.dj.nativeswing.swtimpl.NativeInterface help to make sure that this hybrid SWT/Swing setup works
  
• if you now open the file dialog and after several layers of abstract at some point the Java VM calls the Mac OS to open a window that seems to collide with the Java thread I've throttled with Thread.sleep() which tries to call the native browser component
  
• I guess the reason for this collision is the single threaded approach of either Mac OS communicating with the apps its running or the Java VM executing AWT/Swing apps
  

Does this sound reasonable?

After writing the above, I've looked through the code (again) and searched for places where the access of the browser component could be parallized. Please have a look at EclipseSWTMapView#executeScript and #executeScriptWithResult and remove all the webBrowser.runInSequence( .. ) blocks, i.e.

webBrowser.runInSequence(new Runnable() {
public void run() {
webBrowser.executeJavascript(script);
}
});

becomes

webBrowser.executeJavascript(script);

Does this show any effect?

BTW: I stumbled upon this article (http://nadeausoftware.com/node/90).

I don't understand why you're citing this. What is special about that page?

[hvdwolf]

I understand the connection between the Thread.sleep() and the file dialog as the following:

• in Mac OS X the first thread of a process does the event processing
  
• for Java, it seems the Apple engineers managed to connect this directly to the AWT-EventQueue thread which is the single Java thread used to update the user interface for pure Java apps -XstartOnFirstThread is not necessary
  
• for the browser, I'm using a library (DJNativeSwingSWT) that allows to embed Eclipse SWT components into Javas Swing UI framework
  
• Eclipse SWT consists of native code and Java wrappers (where Java Swing is pure Java)
  
• this means the event processing becomes a problem since events from the operating system must reach the native code components i.e. the browser and the pure Java Swing (via the native Java VM)
  
• -XstartOnFirstThread and the Java class chrriis.dj.nativeswing.swtimpl.NativeInterface help to make sure that this hybrid SWT/Swing setup works
  
• if you now open the file dialog and after several layers of abstract at some point the Java VM calls the Mac OS to open a window that seems to collide with the Java thread I've throttled with Thread.sleep() which tries to call the native browser component
  
• I guess the reason for this collision is the single threaded approach of either Mac OS communicating with the apps its running or the Java VM executing AWT/Swing apps
  

Does this sound reasonable?

I read it 4-5 times and it sounds logical, but I miss the background knowledge on how MacOSX and java interact to be able to judge the validity of your arguments.
However, I googled around a bit and I found this article (homepage.mac.com/svc/macosxjava.pdf) which mentions in section 3.4 to use awt instead of swing for file dialogs. It is terribly old (2001) and I can't judge the correctness of this or whether it is still valid.
If your arguments are correct, it might be that the awt file dialogs might work correctly (or not?)
If I search the code I can see that you use the "javax.swing.FileChooser" function, but I don't know if I can change it easily to experiment with the awt dialog.

remove all the webBrowser.runInSequence( .. ) <snip>
blocks become

webBrowser.executeJavascript(script);

Does this show any effect?

Well, it does, but not with the desired effect. It seems to make everything slower without fixing the popup issue.

BTW: I stumbled upon this article (http://nadeausoftware.com/node/90).

I don't understand why you're citing this. What is special about that page?

Sorry. A copy&paste error. It should be (http://nadeausoftware.com/articles/2009/...ecorations). I just copied it in as "background info" as it is related to the other discussion.

[hvdwolf]

Congratulations with your version 2. It works fine on Linux. I didn't test windows and OSX still has the performance issue.

The past weeks I have been working on an off on the slow OSX performance (more off than on as it gets frustrating if you don't know java and don't have a clue what to fix, but that aside). I googled around and now I found the following link http://support.mozilla.com/tiki-view_for...&forumId=1

I tried that in the relevant .java files (see below) but it doesn't seem to work. Either because it simply doesn't help or because I did it completely wrong.
I also copied it in every mentioned .java file but it could be done more efficient by an include file or whatever.

I included a diff file to this mail. It has the extension .txt otherwise I couldn't add it. Can you have a look at it whether it could work and if I implemented it correctly (I guess not)?

.java files I tried to fix:
route-converter/src/main/java/slash/navigation/converter/gui/renderer/GoogleMapsPositionListCellRenderer.java
route-converter/src/main/java/slash/navigation/converter/gui/renderer/LocaleListCellRenderer.java
route-converter/src/main/java/slash/navigation/converter/gui/renderer/RouteCharacteristicsListCellRenderer.java
route-converter/src/main/java/slash/navigation/converter/gui/renderer/RouteListCellRenderer.java
route-converter/src/main/java/slash/navigation/converter/gui/renderer/RouteServiceListCellRenderer.java

[routeconverter]

Congratulations with your version 2. It works fine on Linux.

Great!

I didn't test windows and OSX still has the performance issue.

The past weeks I have been working on an off on the slow OSX performance (more off than on as it gets frustrating if you don't know java and don't have a clue what to fix, but that aside). I googled around and now I found the following link http://support.mozilla.com/tiki-view_for...&forumId=1

I tried that in the relevant .java files (see below) but it doesn't seem to work.

That means, it has no effect? I'd be really astonished if it would.

[hvdwolf]

That means, it has no effect? I'd be really astonished if it would.

So another useless link/try? Or do I understand incorrectly?

[routeconverter]

That means, it has no effect? I'd be really astonished if it would.

So another useless link/try? Or do I understand incorrectly?

I guess, yes. You've modified the rendering of list cells and overwrote and thus removed all the inherited methods. But there are just two of them on the convert panel and the report is for applets embedded in the browser.

RouteConverter has a complex technology stack for the map display. It's much more likely that the problem lies there, as I explained it above.

Somebody made my think about a completely different approach to avoid that RouteConverter polls the embedded webbrowser. I'm going to implement this in a small prototype on Windows and would be glad if you could test that on Linux and Mac OS X. How about that?

[routeconverter]

Somebody made my think about a completely different approach to avoid that RouteConverter polls the embedded webbrowser. I'm going to implement this in a small prototype on Windows and would be glad if you could test that on Linux and Mac OS X. How about that?

As a first test, please try to execute the first browser test

• BrowserTest1Linux64
  
• BrowserTest1Mac64
  
• BrowserTest1Windows64
  

If successfully started with 'java -jar BrowserTest1Linux64.jar', it should display a window like this:

   

Do you see that?