• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

[DEV] 0.9n wann?

salzkammergut

Geomaster
Gibt es Pläne in nächster Zeit eine 0.9n freizugeben?

Mit all den Änderungen in den letzten Wochen ist CW jetzt schon sehr brauchbar.

Mir würde ein Releasedatum Ende Jänner vorschweben.

Was meint Ihr?

salzkammergut
 

Bilbowolf

Geowizard
Schlage ein Code Cut Datum vor.

Die 0.9n ist schon lange fällig. Ich tendiere sogar dazu eine 1.0 :!: herauszugeben.
 

2cachefix

Geomaster
Also ich kann mir nichts unter einem 'Code Cut Datum' vorstellen, möchte aber vorschlgen vor dem nächsten Release noch eine neue BE zum Testen rauszugeben.
 
A

Anonymous

Guest
Diesem Wunsch möchte ich mich anschließen.
das mit dem Code Cut Datum ist wohl sowas wie ein Code Freeze gemeint - Ein Datum, ab dem die Version eingefroren wird und ab diesem zeitpunkt werden neue Funktionen ins nächte release übergehen und der eingefrorene Stand ist damit die Version 1.0 / o.9n oder so.
Hoff das war jetzt nicht zu kompliziert? :roll:
 

Kalli

Geowizard
Ich würde gerne noch meine Änderungen an den Exportern mit einfließen lassen, sollte bis zum nächsten WE abgeschlossen sein, ist schon zu 80% fertig.
 

pfeffer

Geowizard
also für ne 1.0 finde ich es auch noch zu früh - dafür sind in der neuen zu viele Funktionen neu, die erstmal ausführlich getestet werden müssen.
Aber sehr bald ist sie fällig.

a) Ich möchte noch in der MovingMap hinzufügen, dass man Caches anklicken kann und sich ein Kontextmenü öffnet.

b) eigentlich wäre es schön, wenn das Durcheinander mit den Karten verschwindet bevor wir 1.0 rausgeben:
* das Radar kann verschwinden (wird durch MovingMap ersetzt)
* die Karten, die zu jedem Cache heruntergeladen werden, sollten automatisch kalibrierte Karten (googleEarth) sein. (ist das noch auf Deiner Todo-Liste, Bilbowolf?)

Schöne Grüße,
Pfeffer.
 

Bilbowolf

Geowizard
* das Radar kann verschwinden (wird durch MovingMap ersetzt)

Ich bin da nicht ganz deiner Meinung. Ich finde den Radar einfach geil (aber wenn ich der einzige bin, schreibe ich das ding als Plugin um :D )

Der Radar kann von mir aus verschwinden,wenn man die Moving Map ausblenden kann (das erhöht einfach die Übersichtlichkeit (finde ich)).
 

Kalli

Geowizard
Das Radar sollte drinbleiben, ich habe z.B. keine Karten für die Moving Map.

Ob man maps.google.com für den Kartendaownload nehmen kann möchte ich bezweifeln. So wie ich es sehe, benötigt man dafür einen javascript-fähigen Browser.
 

pfeffer

Geowizard
die MovingMap funktioniert inzwioschen auch vollständig ohne Karte.
Dann werden alle in der Liste markierten Caches angezeigt
außerdem der Track
man kann zoomen und verschieben.

Das einzige, was im Moment nicht geht:
* dieser Kreis um das Zentrum. Wenn das gebraucht wird, mache ich das auch noch rein.

* Und das Kontextmenü fehlt noch, aber das habe ich ohnehin vor.

Ich find, man sollte dem Anwender nicht zu viele sehr ähnliche Funktionen zur Verfügung stellen, deswegen würde ich gern die MovingMap an die Stelle des Radars setzen.

Gruß,
Pfeffer.
 

Bilbowolf

Geowizard
Also: Vor dem nächsten Release kommen sicher noch einige BEs. Mit Code Cut = Code Freeze ist gemeint, daß wir ab dem Zeitpunkt für das neue Release nur noch Bug Fixing machen.

Wegen GM und CW mache ich einen anderen Thread auf.
 
OP
S

salzkammergut

Geomaster
Ich bin auch dafür daß der Radar bleibt.

Etwas off-topic:

@Bilbowolf: Die Idee mit dem Plugin finde ich nicht schlecht. Ich habe schon überlegt ob es möglich ist das Starten von CW zu beschleunigen indem zunächst nur ein ganz einfaches Interface geladen wird, welches nur die Profilauswahl durchführt und eventuell die Listenansicht darstellt. Im Hintergrund läuft ein Thread, der die anderen Panels über einen Classloader aus einer ZIP Datei nachlädt. Wenn auf ein bestimmtes Panel gekickt wird, wird geprüft ob es schon geladen wurde und ggf. wird es bevorzugt geladen.

Derzeit ist mir noch nicht klar wohin genau die Zeit beim Starten verschwindet (mal abgesehen von der index.xml). Ist es nur das Initialisieren der diversen UI-Klassen oder das Laden der vielen Images? Ich will mal prüfen wieviel Zeit die Images brauchen. Leider ist der Timer unter Windows so beschissen, daß es sehr schwer ist da was zu messen.
 

pfeffer

Geowizard
die MovingMap muss sich erst mal bewähren, Ihr habt schon recht.

@Salzkammergut: Deine Ideen hören sich ziemlich cool an! finde ich gut. Hätte allerdings die Hoffnung, dass man noch optimierbares findet. Aber leider gibt es wohl keine freien Profiler für java, die einem die Suche da erheblich erleichtern könnten - jedenfalls habe ich keine gefunden. Ich hätte auch gern so ein Programm, weil ich es seltsam finde, dass es nach ein paar Lade / Zoom-Vorgängen in der MovingMap manchmal zu OutOfMemoryError kommt, obwohl die selbe Aktion vorher 2-3 Mal geklappt hatte....
Hat jemand von Euch eine Idee, wodran es liegen könnte, dass die 338 schneller startete als die neue 400 (wie alle User hier berichtet haben)?

Gruß,
Pfeffer.
 

Kalli

Geowizard
Profiler:
Ich habe mir das TPTP-Plugin für eclipse installiert (siehe auch http://www.yacy-websearch.net/wiki/index.php/De:EclipseTPTPHowto). Ist allerdings ziemlich langsam.

Außerdem habe ich mal das Skript runconsole.bat eingecheckt, wenn man damit den CacheWolf startet, kann man in einer separaten Kommandozeile "jconsole" eingeben, dann sieht man einiges über die Anzahl der Threads, Speicherbedarf etc.

Ich habe jetzt wieder bei den Exportern festgestellt, dass der CacheWolf, wenn er unter java läuft, sauschnell exportiert, nehme ich das ewe-File oder die CacheWolf.exe, wird er deutlich langsamer. Ich werde noch etwas mit Buffered IO experimentieren, beim Import hat dies damals leider nichts gebracht.

Startgeschwindigkeit:
Mit Revision 352 habe ich eine Änderung eingecheckt, mit der addi wpts dem Hauptcache zugeordnet werden. Dafür müssen beim Starten die Referenzen zwischen den Main-Caches und den addi wpts hergestellt werden (siehe CacheHolder.buildReferences())
 

Bilbowolf

Geowizard
Derzeit ist mir noch nicht klar wohin genau die Zeit beim Starten verschwindet (mal abgesehen von der index.xml).

Das einlesen der index.xml dauert etwas, richtig --> aktuell frisst die Änderung von Kalli einiges auf, _aber_ ich habe per Zufall festgestellt, das der Aufbau der Tabelle auch einiges schluckt. Wenn man es auf die Spitze treibt müssten wir unsere eigene Tabelle schreiben :?
 

pfeffer

Geowizard
Noch eine Idee: ich habe noch festegestellt, dass das Umwandeln der Koordinaten von "string" in computer interpretierbares Format viel Zeit in Anspruch nimmt. Es könnte überlegt werden, die Koos direkt in maschinen lesbarer Form zu speichern (z.B. so wie es Kalli? in den .wfl-Dateien für die Kartenkalibrierung gemacht hat - dort geht das Einlesen sehr fix).

@Kalli: danke für die Hinweise auf Profiler!

Gruß,
Pfeffer.
 

Kalli

Geowizard
Die .wfl-Dateien hat Bilbowolf gemacht, Ehre wem Ehre gebührt :D
An die Koordinaten habe ich auch schon gedacht, also direkt als lat= und lon= speichern, dann braucht man nur noch den String zu parsen (mit unserer eigenen Routine, sonst gibt's Probleme mit Punkt und Komma). Das Lesen der index.xml müsste dann natürlich mit beiden Formaten umgehen können, da muss man jetzt etwas aufpassen, da wir nicht mehr mit einem XML-Parser drangehen.
 
Oben