Alle Probleme mit dem Release Candidate 0.9n (RC_672)...

[MiK]

Also rausschmeißen werden wir jetzt bestimmt nichts mehr. Und wenn man instabile Teile entfernen wollte, dann müsste wohl der Import der PQs raus, denn der läuft ja nach Deinen Erfahrungen instabil und nicht die MM.

OK, das ist jetzt meine egoistische Sicht. Die MM nutze ich ständig und den PQ-Import nie.

Wir brauchen eine Liste der Bugs, die wirklich so schwerwiegend sind, dass sie ein Release verhindern. Der erste Punkt sind also die Probleme beim PQ-Import. Kann das jemand der Entwickler nachvollziehen?

Welche schwerwiegenden Bugs haben wir noch?

 

[pfeffer]

sehe ich das falsch?
die Probleme beim PQ-Import lassen sich doch (unbefriegend und nur vorläufig) leicht lösen: einfach die Speicheranforderung (-Xmx weglassen oder ändern für wenn es auf dem PC läuft, wie Kalli schon geschrieben hat).

Ansonsten stimme ich MiK aus meiner egoistischen Sicht voll zu

Schöne Grüße,
Pfeffer.

 

[greiol]

Ich bin mir sicher wir werden alle eine weise Entscheidung treffen.

 

[Inder]

Bitte 0.9n releasen! ...

Meine Sicht, als User:

Ob Release oder BE wäre mir ziemlich egal. Ich finde nur schade, dass die aktuelle BE Fehler hat, die in den vorhergehenden noch nicht da waren (habe ich weiter vorne schon beschrieben) und schaue seither fast täglich nach, ob es schon eine Version mit Behebung dieser Bugs gibt.

 

[2cachefix]

Bitte 0.9n releasen!

Ich bin dafür, mit "known Bugs" zu releasen, sonst kommt es hier nie zu einem Release. Die 0.9n sollte schon im Februar erscheinen. Dass nicht released wird, hindert uns daran (feature freeze)

a) den Code ordntlich zu machen, weil wir nur Löcher stopfen
b) neue Features einzubauen.

Außerdem gibt es hier seit längerem immer wieder Fragen, die nur aufkommen, weil die Leute die letzte "stable" verwenden.

Schöne Grüße,
Pfeffer.

ich bin auch dieser Meinung. das ganze scheint ein wenig aus dem Ruder zu laufen, da offensichtlich immer mehr User zu uns stoßen, die andere Hardwarekonstellationen haben. Auch würden dann alle User sich auf eine bestimmte Version beziehen können. Es gibt einfach zu viele RC's.

 

[2cachefix]

wie ich schon in einem anderen Thread beschrieben habe, wird bei bestimmten Cachebeschreibungen der Text nicht umgebrochen und zum Teil ändert sich die Schrift-Große und -Art. Die führt zu nicht leserlichen Cachebeschreibungen.

Ich vermute, dass es sich um einen Eingabefehler handelt. Evtl. wird jede Zeile mit einen Return bestätigt. Ist es bei der Anzeige nicht möglich einen Textumbruch zu werzwingen? Ich denke an eine Funktion wie beim Windows-Editor.

Ein Beispiel wäre GCWEZ1

 

[salzkammergut]

Schau Dir mal den Quellcode zu GCWEZ1 an. Der ist ganz blöd Zeile für Zeile in font tags eingebettet. Das ist kein Fehler von CW sondern ein Author der keine Ahnung von HTML hat. Der Sinn von HTML ist die Darstellung auf verschiedensten Anzeigegeräten zu ermöglichen und dem Browser den Umbruch zu erlauben. Das ist bei dieser Art der Formatierung aber nicht möglich. Nicht einmal der Firefox kann diese Seite umbrechen wenn Du das Fenster verkleinerst. Sorry.

Grüße
skg

Beispielcode aus GCWEZ1:

<font color="#0000ff" size="+1" face=
"Arial">Diese Serie soll an eine ehemalige, fast vergessene Bahnlinie</font>
<font color="#0000ff" size="+1" face=
"Arial">in Nordhessen erinnern.</font>

 

[2cachefix]

Sowas habe ich mir schon gedacht.
Hat der Ersteller denn die Zeilen tatsächlich so eingegeben? Ist das unnötige Arbeit mit einem eher schlechten Ergebnis?
Schade dass das nicht zu ändern ist.

 

[sparrow]

Das sieht ein wenig nach einem WYSIWYG-Editor aus der nichts taugt.

 

[Windi]

Gibt es eigentlich eine Möglichkeit die von Cachewolf gespiderten Caches in Mapsource zu laden?
Es gibt zwar den Export nach PCX5Mapsource (was immer das auch sein mag) und GPX aber beide Dateien lassen sich von Mapsource nicht öffnen.

 

[snaky]

Ich weiß nicht, ob das ein Anwenderfehler oder wirklich ein Fehler im Programm ist (ich nutze CW erst seit 2 Wochen (und bin begeistert!)), aber was mich stört ist, dass er für die Anzeige von Cachebeschreibungen und Logs teilweise ewig (auf dem PPC mit "schlechtem WLAN") braucht, weil er scheinbar versucht, sich die Bilder online zu holen und nach einer Weile erst aufgibt, obwohl er die entsprechenden Bilder sowieso lokal speichert.

Ich habe z. B. diese Cachebeschreibungen mit den deutschen Cacheicons. Das Anzeigen dauert auf dem PPC zwischen 3 und 5 Minuten je nach Anzahl der Icons.

Ebenso bei den Logs wenn die Logger intensiv Smileys benutzen.

Ach ja: Klagen auf hohem Niveau... Wenn ich beim Spidern von GC nach dem Passwort gefragt werde, erscheint direkt über der Eingabebox beim PPC eine sich drehendes Icon (wohl das Pendant zur Windows-Sanduhr). So erkennt man nicht, ob man beim Passwort einen Tippfehler gemacht hat. Ist aber nicht wirklich tragisch, es war nur in der 0.9m-Version nicht so.

 

[salzkammergut]

@snaky: Erstens: Welche Version?
An Alle: Bitte IMMER Version angeben!

Zweitens: Problem mit "deutschen Cacheicons". Bitte gib Details (Cachename) an - so ist das nicht zu überprüfen.

Generell: Die lange Wartezeit ist nicht normal. CW speichert alle Daten lokal. In den Cachebeschreibungen werden die Bilder nicht dargestellt - dafür gibt es ja die eigene Karteikarte - daran liegt es also nicht.

Der HTML Renderer der EWE Virtual Machine, der für die Log-Darstellung verwendet wird, ist leider sehr langsam (sollte aber im Sekundenbereich und nicht im Minutenbereich liegen). Du kannst in den Präferenzen die Anzahl der Logs, die auf einen Streich dargestellt werden, einstellen (Versuche 5 oder 10).

 

[Anonymous]

Jetzt wollt ich doch nochmal nachfragen: gibt es denn demnächst mal ein neues Release? Es wird hier immer wieder nachgefragt aber ein Statement derjenigen, die es veröffentlichen können hab ich bisher nicht dazu gesehen.
Dabei dürfte es doch etlichen das leben leichter machen. Insbesondere nach dem GC.com Update wäre es doch sinnvoll (ok, vorher das mit dem Spider noch machen).

 

[2cachefix]

Schau Dir mal den Quellcode zu GCWEZ1 an. Der ist ganz blöd Zeile für Zeile in font tags eingebettet. Das ist kein Fehler von CW sondern ein Author der keine Ahnung von HTML hat. Der Sinn von HTML ist die Darstellung auf verschiedensten Anzeigegeräten zu ermöglichen und dem Browser den Umbruch zu erlauben. Das ist bei dieser Art der Formatierung aber nicht möglich. Nicht einmal der Firefox kann diese Seite umbrechen wenn Du das Fenster verkleinerst. Sorry.

Grüße
skg

Beispielcode aus GCWEZ1:

<font color="#0000ff" size="+1" face=
"Arial">Diese Serie soll an eine ehemalige, fast vergessene Bahnlinie</font>
<font color="#0000ff" size="+1" face=
"Arial">in Nordhessen erinnern.</font>

ich habe noch einmal über das Problem nachgedacht. Da nicht auszuschliessen ist, dass auch andere ihre Texte in dieser Form einstellen, müssen wir eine Lösung für dieses Problem finden. Ein Ansatz wäre vielleicht ein horizontaler Scrollbalken. Da ich nicht weiss, ob sowas im CW überhaupt programmierbar ist möchte ich das als theoretischen Ansatz verstanden wissen. Falls das machbar ist würde ich das als FR für die nächste Version aufnehmen.

 

[lahmer]

Ich habe noch ein ganz anderes Problem... kennt jemand den korrekten Pfad des Internet Explorer unter Windows Mobile 5?
Ich habe schon verschiedene Möglichkeiten in den Präferenzen von CW eingetragen... allerdings bekomme ich immer die EWE-Fehlermeldung: "Cannot start browser [...] path to internet browser in preferences not correct or an bug in ewe VM, please be pacient for an update"

Hatte jemand schonmal ähnliche Probleme oder kann mir einen Lösungsvorschlag anbieten?

 

[2cachefix]

Dieses Problem ist bekannt und auf einen Fehler in der ewe-VM zurück zuführen. Inwiefern unsere Entwickler darauf Einfluss haben weiss ich nicht.

 

[snaky]

@snaky: Erstens: Welche Version?
An Alle: Bitte IMMER Version angeben!

Sorry, ich dachte, das ergibt sich aus dem Threadtitel: 0.9n RC672
Die Version für den PocketPC (ohne "ARM" im Filenamen). Das Gerät ist ein Fujitsu Siemens n560.

Zweitens: Problem mit "deutschen Cacheicons". Bitte gib Details (Cachename) an - so ist das nicht zu überprüfen.

Als Beispiel: GCJVZX(A67 - Quickie)

Ladezeit auf dem PPC (624 MHz): 3 Minuten 51 Sekunden
Ladezeit auf dem PC (600 MHz): ca. 1 Sekunde

Das Problem habe ich aber bei allen Caches mit vielen Bildern und ebenso Logs mit vielen Smileys.

Generell: Die lange Wartezeit ist nicht normal. CW speichert alle Daten lokal. In den Cachebeschreibungen werden die Bilder nicht dargestellt - dafür gibt es ja die eigene Karteikarte - daran liegt es also nicht.

Ja, das wundert mich auch. Zumal die lokalen Bilder ja auch gespeichert sind. Ist also nicht so, dass er sie nicht finden könnte.

Was mir gerade noch so einfällt: Könnte das daran liegen, dass ich den CW von der SD-Card auf das Gerät kopiert habe und nur auf das alte Profil verlinkt habe? In der pref.xml ist mir allerdings nichts besonderes aufgefallen.
Wenn ich nachher mal Zeit habe, entpacke ich den CW nochmal neu und gebe nochmal einen Bericht ab.

 

[snaky]

Update: Ist wohl ein klarer Fall von PEBCAK.

Eine neue Version von CW hat nichts gebracht, aber wenn ich den entsprechenden Cache aktualisiere, zeigt er mir den auch schnell an. Offenbar ist ihm das Verschieben des Profilordners nicht gut bekommen.

Also sorry, war wohl mein Fehler.

 

[Christian und die Wutze]

Update: Ist wohl ein klarer Fall von PEBCAK.

Also PICNIC?

Ich kenne das übrigens als PEBKAC oder PEBCAM...

 

[snaky]

Is ja eigentlich wurscht.
Google gibt für CAK "nur" 49.200 Treffer, für KAC 137.000 Treffer, also wirst Du wohl recht haben.