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

Großes Lob und kleiner Verbesserungsvorschlag zu Hints

Silas

Geocacher
Hallo Cachewolf-Entwickler,

zunächst einmal ein riesen Lob an euch: Cachewolf ermöglicht nicht nur super das Papier-lose Cachen und steigert den Spaßfaktor desselbigen, sondern ist dank der Plattformunabhängigkeit auch super als Planungstool auf dem PC geeignet. Dann schnell noch Daten auf den PDA und ab in den Wald ;-) Gäbe es Cachewolf nicht, müsste mans schreiben.

Einen kleinen Verbesserungsvorschlag hätte ich allerdings zum Hint-Decoder. Immer wenn man an einer Stelle eines Multis hängt und sich in den Hints etwas dazu erhofft, ist es ärgerlich, wenn man auch gleich die Hinweise zu den folgenden Stages im Klartext angezeigt bekommt.

Ich fände es daher sehr praktisch, Hints nur teileweise zu dekodieren. Zu diesem Zweck habe ich die Dekodier-Funktion dahingehend geändert, dass immer nur der gerade im Hint-Feld markierte Text dekodiert wird, sofern es eine Markierung gibt. Anderenfalls natürlich der ganze Text.

Meine Änderungen wollte ich als Diff (zum trunk in Revision 1533) eigentlich anhängen (vielleicht haben ja noch mehr Leute Interesse daran), aber weder .diff noch .txt scheint erlaubt zu sein, daher poste ich die drei, vier Zeilen eben hier.

Viele Grüße und weiter so,
Silas von den Cachehörnchen

Code:
Index: HintLogPanel.java
===================================================================
--- HintLogPanel.java	(Revision 1533)
+++ HintLogPanel.java	(Arbeitskopie)
@@ -168,7 +168,12 @@
 				setLogs(crntLogPosition);
 			}
 			if(ev.target == decodeButton){
-				hint.setText(Common.rot13(hint.getText()));
+				Object selection = hint.getSelection();
+				if(selection != null){
+					hint.replaceSelection(Common.rot13(selection.toString()));
+				} else {
+					hint.setText(Common.rot13(hint.getText()));
+				}				
 			}
 		}
 	}
 

MiK

Geoguru
die_cachehoernchen schrieb:
Ich fände es daher sehr praktisch, Hints nur teileweise zu dekodieren. Zu diesem Zweck habe ich die Dekodier-Funktion dahingehend geändert, dass immer nur der gerade im Hint-Feld markierte Text dekodiert wird, sofern es eine Markierung gibt. Anderenfalls natürlich der ganze Text.
Ich habe zwar kein Problem damit, die folgenden Zeilen nicht zu lesen, aber Deine Änderungen stören ja die ursprüngliche Funktionalität nicht. Deswegen spricht von meiner Seite nichts dagegen, es bei Gelegenheit einzubauen.

die_cachehoernchen schrieb:
Meine Änderungen wollte ich als Diff (zum trunk in Revision 1533) eigentlich anhängen (vielleicht haben ja noch mehr Leute Interesse daran), aber weder .diff noch .txt scheint erlaubt zu sein, daher poste ich die drei, vier Zeilen eben hier.
Könntest Du bitte die Diff-Datei zippen und anhängen? Danke!
 
OP
S

Silas

Geocacher
Ja klar, siehe Anhang. Ich habs übrigens unter Ubuntu Hardy mit OpenJDK 1.6.0 und auf meinem HTC P3300 mit Windows Mobile 6 ausprobiert. Würde mich sehr wundern, wenns irgendwo sonst zu Problemen damit kommen sollte, sofern sich das Ewe-Steuerelement überall gleich verhält, was es ja sollte.
 

Anhänge

  • HintLogPanel.java.diff.zip
    432 Bytes · Aufrufe: 4

Engywuck

Geowizard
Nee, so geht's nicht.
Wenn man nämlich wieder zurückverschlüsseln will, muss man wieder selektieren, und zwar genau den Teil, den man vorher selektiert hat. Wenn man sich da vertut (was im Gelände auf dem PDA sicher mal passieren kann), bekommt man sehr aromatische Mischungen aus kodierten und dekodierten Teilen.

Grüße,
E.
 

MiK

Geoguru
Genau solche Einwände habe ich auch eher erwartet als dass es auf einer Plattform nicht geht.

Man müsste sich dann wohl den Zustand der Hints merken und im (teil-)dekodierten Zustand bei Knopfdruck immer wieder den Originaltext einsetzen.
 

MKW

Geocacher
Engywuck schrieb:
Nee, so geht's nicht.
Wenn man nämlich wieder zurückverschlüsseln will,...
Wenn Du den Hint wieder verschlüsselst, vergißt Du ihn dann auch? Im Ernst: warum soll man den Hint wieder verschlüsseln wollen?
 

Engywuck

Geowizard
MKW schrieb:
Im Ernst: warum soll man den Hint wieder verschlüsseln wollen?
Ganz einfacher Fall aus der Praxis: Meine Lebensabschnittsverschönerungsgefährtin will den Hint schon lesen, ich aber noch nicht. Also entschlüssele ich ihn ihr, sie guckt auf das PDA, dann verschlüssele ich ihn wieder.
Wenn ich jetzt den zu verschlüsselnden Bereich noch mit der Maus selektieren müsste, dann käme ich gar nicht umhin, ihn zu lesen...

Gruß,
E.
 

Engywuck

Geowizard
MiK schrieb:
Man müsste sich dann wohl den Zustand der Hints merken und im (teil-)dekodierten Zustand bei Knopfdruck immer wieder den Originaltext einsetzen.
Was ja auch kein Aufwand wäre.
Hätte zudem den Charme, dass man den Text auf dem Button dann von "Decode" auf "Encode" (oder so) ändern könnte. Für die Puristen unter uns ;-)

Gruß,
E.
 

MKW

Geocacher
@Engywuck:
Wie wäre es, wenn Du deiner LAG erklärst, wie Sie sich den Hint selbst decodiert? ;)
 

MiK

Geoguru
Das Problem tritt ja nicht nur auf, wenn man wieder Kodieren möchte. Wenn man immer Teile markiert und Dekodiert, kann es leicht mal zu Überlappungen bei den Markierungen kommen. Dann sind vielleicht halbe Wörter kodiert und man kommt nicht mehr einfach in einen konsistenten Zustand.
 
OP
S

Silas

Geocacher
Ja klar, aber zumindest auf meinem PDA wäre das echt unzumutbar. Die Ansicht zu wechseln dauert einige Sekunden.

Des beschriebenen Verhaltens war ich mir natürlich bewusst, habs aber nicht als Problem wahrgenommen (meine bessere Hälfte würde nie freiwillig einen PDA benutzen ;-))

Ist aber ja grundsätzlich kein Problem, sich den Status zu merken und immer dann, wenn schon einmal mindestens ein Teil des Hints dekodiert wurde, beim Buttonclick den Text auf den kodierten zurückzusetzen.

Lästig wäre da lediglich, dass wenn man hat den ersten Teil des Hints schon dekodiert hat und nun einen weiteren dekodieren möchte, zwei Klicks notwendig sind: Der erste setzt zurück und der zweite dekodiert den neuen Teilstring. Alternativ dazu wäre ein weiterer Button "Encode" oder genauer "Reset" denkbar, aber das kostet natürlich Platz.

Ich persönlich würde zur Methode "Status merken und beim erneuten Klick zurücksetzen" tendieren.

Natürlich könnte man sich auch für jedes Zeichen einzeln den Status merken und immer dann zurücksetzen, wenn in der Menge der markierten Zeichen nicht ausschließlich noch kodierte sind. So könnte man einen noch komplett kodierten Teilstring mit einem Klick dekodieren, würde aber den gesamten Hint zurücksetzen, wenn mindestens ein bereits dekodiertes Zeichen markiert ist oder es gar keine Markierung gibt. Nur was dann auf dem Button stehen sollte, wäre noch unklar.

Weitere Vorschläge?
 

Robin888

Geomaster
Möglichkeit 1

Hilfsmittel
-ein Merker: Irgendetwas decodiert oder nicht?

Handling
1) Text markiert: Markierten Text decodieren.

2.a) Kein Text markiert und Merker auf 0: alles decodieren
2.b) Kein Text markiert und Merker auf 1: Lade Hints neu (Reset)

Bemerkung:
Ist der Merker auf 1 gesetzt (=Teile wurden decodiert) kann man den Button zudem z.B. mit "Decode/Reset" beschriften. (Oder die Beschriftung vielleicht sogar davon abhängig machen, ob Text markiert ist oder nicht. :-D)

Möglichkeit 2

Hilfmittel
Neugeladene Hints standardmäßig komplett markieren

Handling
1) Text markiert: Markierten Text decodieren.

2) Kein Text markiert: Lade Hints neu (Reset)

Bemerkung:
- Ich weiß nicht wie schwierig es ist die Markierung aufrecht zu erhalten, wenn man z.B. in den Logs blättert.
- Der Standardmäßig markierte Hint scheint etwas schwieriger zu lesen zu sein, was verhindern könnte, daß man bekannte Schlagwörter (zntargvfpu, hagre, Onhz) erkennt.

Möglichkeit 3

Hilfmittel
Resetbutton (Platz genug ist IMHO auch auf dem PDA)

Handling
1) Text markiert + [Decode]: Markierten Text decodieren.

2) Kein Text markiert + [Decode]: Alles decodieren

3) [Reset]: Lade Hints neu

Bemerkung
Dies dürfte die rundrum eleganteste Möglichkeitr sein. Einsteigerfreundlich und wahrscheinlich am einfachsten zu programmieren.

In jedem jedem Fall würde ich den Decodebutton allerdings in diesem Zuge mit "ROT13" beschriften, dann weiß jeder was gemacht wird und die "Verwirrung" zwischen de- und enkodieren entfällt.

Robin(888)
 

MiK

Geoguru
Das mit den vier Buttons muss man erst mal überprüfen. Das Problem ist der SIP-Button der relativ unkontrolliert mal in der Mitte und mal rechts auftaucht. Zumindest können wir ihn nicht gezielt unterbinden. Wenn er rechts ist überdeckt er evtl. den rechten Button fast vollständig. Wenner in der Mitte ist, sieht man wahrscheinlich nicht mehr, dass da zwei Buttons in der Mitte sind. Wie gesagt: Das müsste man erst mal ausprobieren.
 

Engywuck

Geowizard
Robin888 schrieb:
In jedem jedem Fall würde ich den Decodebutton allerdings in diesem Zuge mit "ROT13" beschriften, dann weiß jeder was gemacht wird und die "Verwirrung" zwischen de- und enkodieren entfällt.
Immer diese Informatiker-Sichtweisen ;-)
Meine Freundin weiß ganz sicher nicht, was mit ROT13 gemeint ist. Und ich kenne etliche Geocacher, für die ich das auch annehmen würde. Für die Beschriftung würde ich vielleicht "Entschlüsseln" bzw. "Verschlüsseln" vorschlagen - das kann nun wirklich jeder verstehen, der der deutschen Sprache mächtig ist. Und einen zweiten Knopf würde ich auch nicht bevorzugen: Bei Funktionalitäten, die sich gegenseitig ausschließen, ist eigentlich ein Knopf gebräuchlich. (Bsp: StartGPS/StopGPS, Zündschlüssel am Auto...)

Grüße,
E.
 

MiK

Geoguru
Ich bin auch eher für eine Ein-Knopf Lösung. Wenn man nichts markiert bleibt dann alles beim Alten. Falls schon etwas Dekodiert wurde und dann ein Bereich markiert wird, gibt es jetzt zwei Vorschläge:

1. Bei Knopfdruck wird auf jeden Fall resetet.

2. Bei Knopfdruck wird nur der markierte Bereich (de-)kodiert.

Ich finde die erste Möglichkeit, also dass der Knopf immer abwechselnd (Teile) dekodiert und wieder alles zurücksetzt eingängiger und konsistenter. Auch wenn man dann evtls einen Klick mehr braucht, wenn man Satage für Stage dekodieren möchte.
 

klausundelke

Geowizard
MiK schrieb:
Ich bin auch eher für eine Ein-Knopf Lösung.

Zustimmung! :2thumbs:

MiK schrieb:
Ich finde die erste Möglichkeit, also dass der Knopf immer abwechselnd (Teile) dekodiert und wieder alles zurücksetzt eingängiger und konsistenter. Auch wenn man dann evtls einen Klick mehr braucht, wenn man Satage für Stage dekodieren möchte.

...aber mal ganz ehrlich: So oft braucht man das doch auch nicht oder? Am einfachsten wäre es, nur den Hint der entsprechenden Stage zu lesen. Fertig.
Da jetzt einen Haufen Arbeit reinstecken für die 5 Caches bei denen das in Frage kommt... ich glaube da gibt es notwendigere Baustellen, die deutlich mehr Nutzern zu Gute kommen würden oder?
Und wenns denn schon sein muss:
1x klicken: Bereich gewählt: diesen decodieren ansonsten alles
Beim 2. Klick: Alles wieder codiert darstellen!
Die Möglichkeit nur teilweise wieder zu codieren macht doch keinen Sinn oder?

Gruss Klaus
 
OP
S

Silas

Geocacher
Wie schon gesagt, wäre ich auch für die einfache Lösung, für die sich auch MiK und Klaus ausgesprochen haben. Wenn dann zwischenzeitlich "Reset", "Encode" oder von mir aus auch "Encrypt" (ich würds in dieser Reihenfolge bevorzugen, weil richtiger) auf dem Button steht, ist auch immer klar, was beim Klicken passiert.

Etwas OT, aber verwandt wegen der Button-Beschriftung: Wie verhindert ihr, dass die gleiche LokalisierungsID von zwei verschiedenen Leuten, die beide die GUI erweitern, gleichzeitig vergeben werden? Wird die DE.cfg im SVN gesperrt? Oder gibts eine andere Stelle (habe jetzt nur flüchtig in den Quelltext geguckt)?

Ich bin übrigens auch der Meinung, das ROT13 nicht unbedingt ein gängiger Begriff ist.

Grüße, Silas
 

Engywuck

Geowizard
die_cachehoernchen schrieb:
Wie verhindert ihr, dass die gleiche LokalisierungsID von zwei verschiedenen Leuten, die beide die GUI erweitern, gleichzeitig vergeben werden?
Gar nicht.
Der zweite, der das Commit durchführt (genauer: Das Update vor dem Commit), würde einen Konflikt in der DE.cfg bemerken, und wäre dann gefordert, den Konflikt durch Verwendung einer anderen noch freien Nummer zu umgehen.

Grüße,
E.
 

MiK

Geoguru
Außerdem hat eigentlich jede Klasse einen eigenen ID-Bereich (was leider teilweise nicht richtig durchgezogen wurde). Dadurch kann es nur dann zu Konflikten kommen, wenn an der gleichen Klasse gearbeitet wurde.

Ansonsten regelt das, wie erwähnt, die Versionsverwaltung.
 
Oben