Meshviewer v11.0.0


#1

Hallo,

Meshviewer v11.0.0 release istbald fertig. Dokumentation wurde aktualisiert.

  • [!!!][TASK] Router hash form # to #! (indezierbar)

  • [TASK] Inject title in metatags (and title) - (less hardcoded)

  • [TASK] Add optional fullscreen mode (Entweder immer verfügbar oder nur als iframe embed - via config)

  • [TASK] Domain code adjustments [noch fehlend]

  • [TASK] GeoJSON support - erlaubt einzeichnen von Elementen in die Karte

  • [TASK] Night mode color adjustments

  • [TASK] NodeJS v10 support, removed v9 support (active v6,v8,v10)

  • [TASK] Add possibility for custom links e.g. DSGVO
    image

  • [TASK] Add OpenGraph, twitter card & Microdata + Favicon update
    image

  • [TASK] Simple offline service worker

  • [TASK] Add source/target address to link variables with fallback (babel support)

  • [TASK] Show rectangle gateway in forcegraph
    image

  • [TASK] Show offline in graph (Vermeidung von toten links)
    image

  • [TASK] Dependency updates

  • [BUGFIX] URL router can fail at high load

  • [BUGFIX] Loadavg with multiple cores in %

  • [BUGFIX] Allow negative coordinates

  • More detail in the commit history

https://doc.meshviewer.org/changelog.html

Vielen Dank an alle contributors & bitte Bug Reports auf github!
:tada::star_struck:

Code auf GitHub

Viele Gruesse
xaver


#2

Vielen Dank für deine ganze Mühe und Arbeit damit.

Arbeitet der schon mit dem Multidomänen-Feature von Gluon 2018.1 zusammen?


#3

Ich vermute Domaincode wurde noch nicht angepasst, da lang die Frage war, was genau geändert werden soll bzw. was mit dem site_code passiert.

Aktuelle Stand:

  • Es muss in yanic der Output meshviewer.json angepasst werden.
  • Wir werden site_code / domain_code machen
    • Es hieß das es bei Domaincode zu Überschneidungen kommen kann
    • Allgemein wurde sich leider wenig gedanken gemacht wie man das ganze gut aufbaut. Meine Idee persönlich wäre wie in Java packages de.freifunk.regensburg.stadt at.funkfeuer.wels.umland oder so. Dann wuerde ich sogar gerne die site_code weglassen. Jede Community nutzt aktuell den site_code sehr unterschiedlich - erkennt man hier ganz gut meshviewer/config.js at multiple · ffrgb/meshviewer · GitHub
  • Es wird dann ein Filter für die Kombination geben könnte auch site_code1 / domain1 site_code1 / domain2 sein. und kann gefiltert werden. Ausgabe im Node detail kann man ja seit v10 auch Anpassungen via JS machen und anderes splitten oder anzeigen.

(Ansonsten nutzten wir 2018.1 als stable release und läuft soweit)


#4

Nach Lehrbuch ist site_code für alle abgefrühstückten »Domains« identisch und die Domain-Daten tauchen AFAICS nirgends auf. Da ist auf zuvielen Ebenen unsinnig, sodaß


#5

Es ging darum wie dieser im Meshviewer genutzt wird. side_code gw gwv6 und domain code als filter ist unsinnig - da kann man gleich eine Readme vorschalten. Daher wird es jedenfalls nur ein Filter geben und beide werte in Kombination, da es hieß das domain code über mehrere communities hinweg nicht unique ist.


#7

So noch paar Änderungen für v11:

  • Title wird an viel mehr stellen via gulp gesetzt (metatags, offline.html usw.) - Weniger Anpassungen nötig falls eine Anpassung gewünscht ist.
  • Fullscreenmode verfügbar (Entweder immer oder nur wenn Meshviewer via iFrame läuft - via config)

Zudem Test (Pull request aktuell) als Locationpicker in luci:

  • Idee wäre offline serviceworker auszubauen und dann die Karte auch ohne Internet aus dem Cache zu nutzten samt Map&nodes.
  • Implementiert via Message um CORS, X-Frame-Options, CSP usw zu vermeiden. und in Luci paar Zeilen Lisener Window.postMessage() - Web APIs | MDN
  • Allgemein mehr Messenger zur Verfügung zu stellen um Embed die Kommunikation zu vereinfachen (nicht nur für location).
  • Privacy Policy, Tiles usw. alles wie auf der Webseite
  • Arbeit basiert auf @tata Arbeit für eine bessere Auswahl.

Release ist aktuell nach dem domain_code Einbau geplant. Gerne können Übersetzungen aktualisiert werden oder weitere hinzugefügt usw.


#8

Alea iacta est, wir haben v2018.1 dahingehend geändert, daß bei gluonutil_has_domains() gilt:

  • gluon_site_code enthält den site_code
  • site_code enthält den domain_code
  • domain_code enthält den domain_code

Rationale: der domain- ersetzt mit Multidomain faktisch den site-code, der site_code ist/war aber Unterscheidungsmerkmal in bisheriger Mappingsoftware: firmwareseitige Anpassung ist nötig.

Insofern wäre es schön, wenn …

… der geplante Filter hinreichend offen wäre, die Variablen frei zu benennen.


#9

Also wie gesagt ich waere den weg mit wenigsten problemen gegangen.
Meshviewer wird nie viel machen nur die Eigenschaft für node Objekt wird anderes gefüllt und so ist es sicher unique. Beispielsweise ffrgb / ffrgb_cty oder so. In der Node kannst du das umbauen usw, Filter code ist noch nicht refactored, daher auch nicht in URL usw. Filter splittet einfach jeden wert der anderes ist als getrennte Position.

@wusel soweit ich sehe nutzt ihr eh nicht den Meshviewer von ffrgb, sondern eine alte Version.


#10

Yepp, und es wird mal wieder Zeit für Renovierungen. Hopglass war eigentlich die Wahl, Testinstallation läuft auch schon, aber das ist ja wohl eine Sackgasse.


#11

Also Benennung kann via Translation einbauen wie man will. Würde es eh Sektion betiteln oder so. Unabhängig von Firmware, yanic usw. Feld bleibt so, um keine unnützen Komplikationen zu verursachen.

[Offtopic]
Also yanic kann einiges, auch forward von respondd usw. Also sollte schnell testweise laufen. Meshviewer vs Hopglass frontend kann sich jeder aussuchen usw. yanic kann eh beides ausspucken. Glaube Hopglass hat auch mal mit meshviewer.json rumgespielt und anfangs auch auf multi map vertreten gewesen.
[/Offtopic]


#12

Weitere Anpassung:

Kleiner XSS fix im Tooltip auf der Karte (ähnliches Problem auch in Hopglass und vermutlich allen anderen Versionen vorhanden)