Bei den Optionen ist mit aufgefallen, dass geo.option.style irgendwie die Optionen von L.circleMarker überschreibt.
Beim Tooltip hatte ich ziemliche Probleme dort eine HTML-Formatierung hineinzubekommen und habe es im Endeffekt erstmal gelassen.
Als kleine Unschönheit kommt außerdem noch hinzu, dass die eingefügte Daten (Marker, Polygone) auf den Ebenen wandern … erst sind sie ganz oben und rutschen dann mit den Nodedaten-Updates nach unten.
Kein Stress … ich hatte nur gerade Zeit und wollte das neue Feature mal ausprobieren.
Breaking commit ist jetzt durch - Es benötigt einen aktuellen yanic der domain statt site zurück gibt. Site wurde jetzt nach X Diskussionen ganz weggelassen. v11 ist näher (hab aktuell viel anderes zu tun).
@wusel Also mein Standpunkt war das es nie 2 verschiedene geben wird. Entweder eine oder andere bzw. beide als ein String. Soweit ich es in Erinnerung hab wird yanic das ummappen, wenn es noch kein doamin_code gibt. Rest kannst via Translation anpassen.
@rotanid also NaN ist schlecht usw. da sorting dann nicht mehr klappt, Farbberechnung der Linien usw. Würde das ganze mit 0 gleich setzten, also es besteht keine Verbindung/keine Info - Farbe ist dann rot.
@wusel Du kannst ja jederzeit eine ältere Version nutzten oder Naming ändern. Dazu brauchst kein großen fork. Das ist eine json Datei. Es ist logisch das man keine 2 Sachen Mitschleppen will bis irgendwann (sehr unterschiedlich die Pflege und Updatefreudigkeit). Letzte Lösung hat im IRC niemand gegen gesprochen, sondern immer dafür ausgesprochen.
Kannst es ja auch bei Domain belassen wenn es der site_code ist. Viele werden die Segmentierung nicht verstehen was der Wert bedeutet.
Kannst auch mit den anderen Reden ob man Statt Domain Segment schreibt und dann ist es egal ob da gerade Domain oder Site verwendet wird.
Das ist der übliche Weg: einen passablen Status Quo hinzustellen und das sollte dann 2-3 Jahre auch tun. Soviel JS kriege ich wohl hin, daß statt xxxy zzzx als Variable/Wert genommen wird: paßt schon.
Ehrlichgesagt hat mich das auch so ein bisschen gestört und ich hatte daher angeboten die config etwas zu externalisieren, d.h. dass sie nicht mittels gulp ins komprimierte js file mit reingeschrieben wird.
Dadurch ließe sich erzielen, dass man in einem ansonsten komplett „sauberen“ (d.h. git status liefert keine diffs) git checkout von meshviewer seine eigenen config daten anwenden könnte.
Ich hatte aber vorab im IRC gefragt ob diese Änderung eine chance darauf hätte upstream zu gelangen. Dies wurde verneint und daher habe ich von einer Implementierung abgesehen. Zumal ich dem @xaver und @genofire da nicht unbedingt dinge auferlegen will, die sie nicht selbst maintainen können oder wollen. Ich bin mehr als froh und dankbar, dass sich da welche gefunden haben, die dieses fundamental wichtige Projekt für unsere Freifunkgruppe vorantreiben.
Naja wie schon geschrieben. Ändern werden wir nichts. Git soll eine funktionierende config haben. Nächste beschwert sich das Repo nicht ohne Anpassung baut oder warum nirgends steht das sich die config geändert hat.
Genauso das 2-3 Jahre laufen soll, dann nimm anderes Release wie v10. Plane nicht für Features mehrere Versionen maintainen. Solang das heute baut passt es und wenn man dazu yanic updaten muss ist es auch OK.
funktionieren die bidirektionalen TQ-Werte inzwischen korrekt mit diesem Release?
Es wurde ja explizit gefragt ob noch was offen ist, da wäre es ja schön wenn das angesprochene dann auch gelöst wird
Also der code im meshviewer passt. Meshviewer release ist ja kein yanic release. Yanic uebernimmt glaube bei nicht vorhanden wert aktuell den anderen anstatt 0 oder so