Probleme mit der Karte unter Mac OS X

[routeconverter]

> ich habe gerade das Prerelease 2.7 getestet. Das hat das gleiche Problem
> wie 2.6. Sobald ein Ort eingegeben ist, läßt sich die Karte nicht mehr
> bewegen.

Verstehe ich das richtig? Der Rest des Programms funktioniert noch, doch die Karte wird nicht mehr aktualisiert?

> Ich habe versucht, Dir den internen Fehlerbericht zu schicken.
> Ich bekam mehrmals die Aufforderung, mein Passwort einzugeben und weiß
> nicht, ob Du den Bericht jetzt fünfmal oder gar nicht bekommen hast.

Ohne Name und Paßwort, d.h. eine Anmeldung beim RouteConverter-Server kannst Du keinen Fehlerbericht abschicken.

> Ich habe die Meldung in ein Textdokument kopiert. Das ist sagenhafte 740
> Seiten lang geworden.
> In der Hoffnung, daß es Dir das was hilft.

Ich schaue mal durch... zumindest sehe ich Deine Nachricht die Du mir zum Fehlerbericht senden wolltest.

Und aus irgendeinem Grund schickt der Webbrowser, den ich für die Karte einbette, ungeheure Mengen an Requests an den RouteConverter-Prozeß, um z.B. mitzuteilen, daß sich das Zentrum der Karte geändert hat. Das sieht dann so aus:

22.03.2012 12:33:56 slash.navigation.converter.gui.mapview.BaseMapView processLines
FEIN: processing line GET /206/centerchanged HTTP/1.1
22.03.2012 12:33:56 slash.navigation.converter.gui.mapview.BaseMapView processLines
INFO: ignoring callback number: 206 last callback number is: 206

Normal ist das nicht, das passierte seit dem Beenden des Dialogs um 12:33:50 über 400(!) Male. Ein einziges Mal wäre üblich.

Der Webbrowser gibt sich aus als:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.54.16 (KHTML, like Gecko) Safari/522.0

Ist das die aktuelleste Version bei Mac OS X 10.6.8?

[routeconverter]

Ich habe jetzt einen zweiten und dritten Fehlerbericht erhalten, die dasselbe Muster haben: der Rechner kommt fast zum Stehen, da der Webbrowser nur noch center_changed AJAX-Requests verschickt.

Ich habe gerade eine neue Vorabversion hochgeladen, die diese Requests nun explizit asynchron verschickt. Vielleicht hilft das... Bitte testet und berichtet.

[bmklaus]

Hallo Christian,
das Problem besteht fort.
Ich habe diesmal auch eine bestehende Karte geladen. Die Route wird nicht angezeigt, und das Kartenfenster ist nicht bewegbar.

Ich schicke Dir den Fehlerbericht per e-mail, die Datei ist zu groß zum hochladen.

viele Grüße,

Klaus.

[routeconverter]

Hallo Klaus,

vielen Dank fürs Testen. Was ich nicht verstehe ist, daß schon mit der Version 2.4 jeder AJAX-Request doppelt gesandt wurde. Mit der 2.7 sogar drei Male

GET /9/centerchanged/46.910649732419536/8.61626841796918 HTTP/1.1
GET /9/centerchanged/46.910649732419536/8.61626841796918 HTTP/1.1
GET /9/centerchanged/46.910649732419536/8.61626841796918 HTTP/1.1

Ich muß mal ein bißchen umbauen und melde mich dann mit einer neuen Vorabversion zurück.

[routeconverter]

Ich muß mal ein bißchen umbauen und melde mich dann mit einer neuen Vorabversion zurück.

Hallo,

neuer Versuch, neues Glück: Ich habe in der Vorabversion, die ich gerade hochgeladen habe, versucht, die vielen mehrfach gesendeten AJAX-Requests zu reduzieren. Bitte probiert mal aus und berichtet, wie sich das so anfühlt.

[cbfschubser]

Hallo Christian,

ich finde dein Programm auch sehr gut und würde gerne helfen so weit ich kann.
Ich habe den gleichen Fehler wenn ich das Programm über den app-Link im Finder aufrufe, dann hängt immer alles und nix geht mehr, zuppele ich aber mal kurz am Frame (grösser oder kleiner machen) dann gehts wieder. Ich würde auf ein Fokus-Problem tippen. Um mal zu sehen ob was auf der Console geloggt wird hab ich das Programm dann mal per java -jar RouteConverterMac64.jar gestartet. Dann lief es auch völlig fehlerfrei.

Gruss

Thomas

[routeconverter]

ich finde dein Programm auch sehr gut und würde gerne helfen so weit ich kann.

Das freut mich, ich kenne mich bei Macs nicht so gut aus und kann Tester immer gebrauchen.

Ich habe den gleichen Fehler wenn ich das Programm über den app-Link im Finder aufrufe, dann hängt immer alles und nix geht mehr, zuppele ich aber mal kurz am Frame (grösser oder kleiner machen) dann gehts wieder.

Das Muster, das alle Nutzer berichten, die den Fehler beobachten.

Ich würde auf ein Fokus-Problem tippen. Um mal zu sehen ob was auf der Console geloggt wird hab ich das Programm dann mal per java -jar RouteConverterMac64.jar gestartet. Dann lief es auch völlig fehlerfrei.

Das spricht gegen ein Fokusproblem und dafür, daß es an den Unterschieden zwischen der JAR- und der .app.zip-Varianten liegt, oder?

Ich vermute, es liegt an -XstartOnFirstThread in

java -XstartOnFirstThread -Xmx512m -jar RouteConverterMac64.jar

Bitte starte einmal mit und ohne den Parameter. Liegt es daran?

[cbfschubser]

Das spricht gegen ein Fokusproblem und dafür, daß es an den Unterschieden zwischen der JAR- und der .app.zip-Varianten liegt, oder?

Ich vermute, es liegt an -XstartOnFirstThread in

java -XstartOnFirstThread -Xmx512m -jar RouteConverterMac64.jar

Bitte starte einmal mit und ohne den Parameter. Liegt es daran?

Ja, es liegt daran. Mit dem o.g. Aufruf sind die Probleme wieder da. Dennoch würde ich vom Gefühl her sagen, dass es ein Fokus-Problem ist, dass nämlich der Fokus grad irgendwo ist, nur nicht da wo ich ihn haben möchte, nämlich um die Karte zu ziehen, oder von Anzeige Route auf Wegpunkte umzuschalten (bzw. das Umschalten geht, aber die Anzeige schaltet nicht um). Wenn ich dann am Frame zuppele, werden ja normalerweise alle enthaltenen Steuerelemente resized oder frisch gerendert und dann wird sozusagen die Anzeige wieder mit den eingestellten Werten gesynct, weil z.B. die Karte dann korrekt im Wegpunktmodus angezeigt wird, und der Fokus ist dann auch auf der Map, die ich dann ziehen kann.

Kannst du mir Stellen im Code nennen, wo man schauen kann, bzw. ich könnte versuchen das mal zu debuggen.
Ich werde aber erstmal die neue Vorabversion versuchen und schauen wie es da ist, dann schaue ich mal ob ich den Code bei mir zum Laufen bekomme und ein wenig reinschauen.

Gruss
Thomas

[routeconverter]

Ja, es liegt daran. Mit dem o.g. Aufruf sind die Probleme wieder da.

Klasse, jetzt müssen wir nur noch herausfinden, warum seit RouteConverter 2.5 immer mehr Mac OS X-Nutzer über dieses Problem klagen (wahrscheinlich alle, die die .app.zip-Version herunterladen), bei Version 2.4 jedoch nicht.

Welche Mac OS X-Version benutzt Du? Welche Java-Version läuft dort? Wie verhält sich die RouteConverter 2.4-Version auf Deinem Rechner?

Die 2.4er gibt es hier

• http://static.routeconverter.com/downloa...terMac.jar
  
• http://static.routeconverter.com/downloa...ac.app.zip
  
• http://static.routeconverter.com/downloa...rMac64.jar
  
• http://static.routeconverter.com/downloa...64.app.zip
  

In der 2.4 war DJNative Swing 0.9.9-20110113, Eclipse SWT 3.6, JNA 3.0.7 an Bord.
Bei der 2.5 waren es DJNative Swing 1.0.2-20110706, Eclipse SWT 3.7.1, JNA 3.2.4.
Und bei der 2.6 sind es DJNative Swing 1.0.2-20111120, Eclipse SWT 3.8M4, JNA 3.2.4.

Da könnten Änderungen an AWT aber auch Änderungen an der Eventverarbeitung von SWT eine Rolle spielen.

Dennoch würde ich vom Gefühl her sagen, dass es ein Fokus-Problem ist,

Hintergrund des Fehlverhaltens ist, daß bei Mac OS X zwingend der Thread 0 die Eventverarbeitung in einem Prozeß übernehmen muß, was genau -XstartOnFirstThread macht.

Details hier und hier

Bei RouteConverter wird das besonders lustig, daß es eigentlich eine Swing/AWT-Anwendung ist, die jedoch für die Karte über den Swing-Wrapper DJNative Swing ein Webbrowser-Control von Eclipse SWT einbettet. Lustig ist das deshalb, weil sowohl Swing/AWT als auch SWT eigene Eventqueue besitzen - wo landen wohl die Events vom Betriebssystem?

Kannst du mir Stellen im Code nennen, wo man schauen kann, bzw. ich könnte versuchen das mal zu debuggen.

EclipseSWTMapView sowie Application sind ein guter Startpunkt. Bevor Du irgendwelche Fokusprobleme debuggst: der Schlüssel ist m.E. die Koexistenz von Swing/AWT und SWT Eventqueue. Möglicherweise haben einfach Änderungen irgendwo im Stack dazu geführt, daß -XstartOnFirstThread nicht mehr benötigt wird. Irgendwo habe ich gelesen, daß man erst Swing/AWT aktivieren soll per Toolkit.getTookit().wasWasIch() bevor man die SWT-Eventqueue startet. Das macht eigentlich chrriis.dj.nativeswing.swtimpl.NativeInterface.runEventPump().

Ich werde aber erstmal die neue Vorabversion versuchen und schauen wie es da ist, dann schaue ich mal ob ich den Code bei mir zum Laufen bekomme und ein wenig reinschauen.

Du kannst Java entwickeln unter Mac OS X? Juche, so jemanden habe ich schon lange vermißt seit Harry van der Wolf damals die Mac OS X-Version von RouteConverter zum Laufen gebracht hat.

[cbfschubser]

Welche Mac OS X-Version benutzt Du? Welche Java-Version läuft dort?

Ich habe OS X 10.6.8 mit java 1.6.0_31

Wie verhält sich die RouteConverter 2.4-Version auf Deinem Rechner?

Die 2.4er läuft gar nicht, zumindest das jar über deinen Link gezogen und per java -jar RC.jar aufgerufen geht nicht. Das app.zip file meldet nach auspacken, dass es korrupt ist.

Da könnten Änderungen an AWT aber auch Änderungen an der Eventverarbeitung von SWT eine Rolle spielen.
Hintergrund des Fehlverhaltens ist, daß bei Mac OS X zwingend der Thread 0 die Eventverarbeitung in einem Prozeß übernehmen muß, was genau -XstartOnFirstThread macht.

Da kenn ich mich zuwenig mit aus, ich programmier sonst eher Backends auf AppServern und deren Web-Frontends. Aber ich wollte schon immer mal was anderes machen, und ich brauche einen schönen Routenplaner für mein TomTom, deshalb ist das hier genau mein Projekt.

Bei RouteConverter wird das besonders lustig, daß es eigentlich eine Swing/AWT-Anwendung ist, die jedoch für die Karte über den Swing-Wrapper DJNative Swing ein Webbrowser-Control von Eclipse SWT einbettet. Lustig ist das deshalb, weil sowohl Swing/AWT als auch SWT eigene Eventqueue besitzen - wo landen wohl die Events vom Betriebssystem?

ich wollte schon sagen...SWT ist doch Eclipse-Stuff und sieht anders aus. Klingt kompliziert, gibts kein BrowserControl für Swing/AWT? Um das zu vereinfachen? Oder sollte man das komplett auf SWT umstellen mit Eclipse RCP?

EclipseSWTMapView sowie Application sind ein guter Startpunkt. Bevor Du irgendwelche Fokusprobleme debuggst: der Schlüssel ist m.E. die Koexistenz von Swing/AWT und SWT Eventqueue. Möglicherweise haben einfach Änderungen irgendwo im Stack dazu geführt, daß -XstartOnFirstThread nicht mehr benötigt wird. Irgendwo habe ich gelesen, daß man erst Swing/AWT aktivieren soll per Toolkit.getTookit().wasWasIch() bevor man die SWT-Eventqueue startet. Das macht eigentlich chrriis.dj.nativeswing.swtimpl.NativeInterface.runEventPump().

Da muss ich mich erst heftigst reinfummeln, weil noch nie gemacht. Vielleicht braucht man das startOnFirstThread nicht mehr, immerhin gehts ohne besser als mit. Ich google mal danach, bzw. wenn du Tips/Links hast dann her damit.

Du kannst Java entwickeln unter Mac OS X?

Naja, auf Arbeit mach ichs unter Windows (mit ant und CVS) insofern ist Maven und git schon eine Herausforderung (+ java, swing, awt unter Mac OS). Aber ich habe den Code lokal am Laufen (soo schlecht ist Maven nicht!!) und kann ihn auch debuggen, bloss verstehen tu ich noch nicht so viel davon, deshalb werde ich noch einen Moment brauchen. Aber ich will in 3 Wochen in Urlaub und will (oder muss!) die ganzen Touren mit RC planen.
Was ist mit Harry los? Lebt der nicht mehr, oder ist er umgestiegen auf Windows?

So long for today...

Gruss
Thomas