Meshviewer Mods auf Basis v4


#41

Ich habe ab März voraussichtlich wieder Zeit PRs abzuarbeiten.

Es ist toll, dass ihr an dem Projekt mitwirken möchtet. Mir gefällt lediglich nicht, dass es jetzt mindestens fünf verschiedene Varianten gibt, die alle ein bisschen anders sind aber alle gleich heißen. Das empfinde ich als unfair, denn es ist mein Projekt, das ich so benannt habe.

Mitarbeit bedeutet dabei für mich, dass man möglichst einwandfreien Code schreibt und den mit ausführlichen Commitmessages einreicht. Selbst ein kleiner Patch, der evtl. nur eine Zeile änderte, sollte eine Commitmessage haben, die das Problem und die Lösung beschreibt. Das erleichtert den Reviewprozess ungemein, da der Reviewer dann nicht mehr den Code interpretieren muss um zu erahnen, was das Problem gewesen sein könnte und was das neue Feature überhaupt tut (und wie es zu bestehenden Features passt).

Oft gibt es auch ein längeres Ping-Pong-Spiel in dem der Patch dann weiter erarbeitet wird. Das ist natürlich zeitintensiv. Wenn ich Patches in andere Projekte (z.B. OpenWrt) einreiche, bin ich auch nicht immer glücklich darüber, dass Monate vergehen in denen sich das niemand anschaut.

Ich plane, wahrscheinlich nachdem wir eine Layer3 Meshstruktur haben, auch den Meshviewer nochmal zu überarbeiten (habe da ja noch einiges vor). Bis dahin würde ich gerne vermeiden, dass die Forks so weit divergieren, dass das Zusammenführen später aufwändig wird. Wenn wir kürzere Reviewzyklen benötigen, könnten wir ansonsten vielleicht auch einen oder zwei weitere Entwickler finden, die den Entwicklungsprozess ähnlich wie ich sehen. Dann hinge es nicht mehr allein von mir ab.

Ich bin zur Zeit in ziemlich vielen Freifunkprojekten aktiv (Gluon, Gluon status page, Meshviewer, l3roamd, verteiltes DHCP, Gatewayconfig, ecdsautils, ffmap-backend) und ich arbeite daran meistens so, dass ich mir ein paar Tage oder Wochen im Jahr intensiv Zeit dafür nehme.

Aktuell steht für den Meshviewer übrigens eigentlich mal die Umstellung auf Version 2 der nodes.json an. Es ist immernoch ein großes Problem, dass master und dev-Branch in der Hinsicht nicht miteinander kompatibel sind. Vielleicht hättet ihr Lust euch darum zu kümmern?


#42

Wieso nicht einfach dynamisch je nach Version parsen? Da kann ich mich dransetzen…


#43

Das wäre mir zuviel Code. Meine Designentscheidung die Knoten als Objekt zu übertragen, war nicht gut und hat den Code an vielen Stellen kompliziert gemacht (das schlägt sich merkbar in der Ladezeit wieder). Darum würde ich da gerne wieder eine Liste daraus machen.

Die nächsten Schritte wäre jetzt eigentlich nur daraus je ein backend und meshviewer Release zu machen, das die Umstellung enthält. Dazu müsste mal $jemand schauen, welche Features aus dem dev-Branch schon gut genug sind um sie als v5 zu veröffentlichen bzw. die restlichen Bugs fixen und die Changelog erweitern.


#44

Das Problem ist, dass jeder eine andere Sicht von “gut genug für release” hat. Viele verwenden die Filter liebend gerne. Ich habe den Hostname-Filter rausgenommen, weil er mir noch nicht “gut genug” ist. Du hast das Feature in einer seperaten branch ruhen lassen.
Den Job kannst nur du machen, wenn du willst, dass die Entscheidungen mit deiner Meinung übereinstimmen.


#45

Ja, der Filter ist bei mir ein einem extra Branch, weil es noch alles andere als fertig ist. Ansonsten ist der dev-Branch wahrscheinlich in einem guten Zustand.

Ich würde das Release wohl etwa im Sommer machen. Im Prinzip könnte es das aber auch jetzt schon geben. Man müsste:

  • Die Changelog entsprechend erweitern (kann jeder)
  • Den dev-Branch in den master mergen (kann ich schnell machen)
  • Das Release als v5 taggen (ebenso)
  • Auf Github aus dem Tag ein Release erzeugen (mach ich dann auch, ist nur copy&paste der Changelog)
  • Das Release hier im Forum bekanntgeben (kann dann auch jeder)

Zudem habe ich gerade noch einige Aufgaben in meiner todo.txt für v5 gefunden:

  • doppel X Pfeil loswerden
  • dialog für layerwahl, mit Add button. anderer add Button dafür weg machen
  • doku: zoom tasten + und - in about dokumentieren
  • doku: legende für karte und graph!
  • new / lost als flag

Hättet ihr Lust euch damit zu beschäftigen?


#46

Lust ja, Zeit… auch bald!
Was ist mit doppel X pfeil gemeint?
Legende für Karte und Graph kann ich mal probieren.


#47

“doppel X pfeil” ist tatsächlich wenig aussagekräftig. Damit ist gemeint, dass in der Detailansicht eines Knotes sowohl ein X zum Schließen der Ansicht als auch der Ausblendepfeil zu sehen ist. Das finde ich wenig intuitiv, habe aber auch noch keine schöne Lösung gefunden.


#48

Hallo @tcatm,

beim Meshviewer steht seit längerer Zeit “This project currently has no maintainer.”. Vielleicht solltest du diese Nachricht anpassen damit klar ist, dass du noch an dem Projekt arbeitest. DIeser Hinweis war auch ein Grund, wieso wir in Hamburg auf den Fork von plumpudding gewechselt haben.

Viele Grüße


#49

Als Hinweis:

Ich lösche heute Abend (19 Uhr) alle meine Freifunk bezogenen Repo’s

Warum:
Mir ist die Lust vergangen, wenn man von seiner lokalen Gruppe “für doof gehalten”(keine Ahnung was passend wäre) wird.

Man verbessert was / anscheinend nicht gewünscht / daher stelle ich mein Engagement für Freifunk ein.
(Meine Zeit kann ich sinnvoller Nutzen)

Lösche meine Repos da wenn ich was beende einen klaren Schlussstrich ziehe … wenn dann richtig.
wenn aus dem noch verbleibenden Repo jemand noch etwas braucht wie gesagt bis 19 Uhr ist es noch auf Github.

Ich halte es immer so erst mal eine Nacht darüber zu Schlafen … und wenn 24h später ich immer noch so denke es durch zu ziehen -> 2. trat nun ein…

Auf ein 2. “2. Augsburg” habe ich keine Lust :wink:

Gruß
Daniel


#50

Hä?

Ich finde die Mods toll.

Naja, musst du wissen. Schade.


#51

Wegen den Router Bildern:

Wie funktioniert das?

gibt es irgendwo eine Seite, wo man die routerpics alle runterladen kann? Um sie woanders weiterzuversenden?


#52

ich bin dran alle von gluon unterstützen router nach zu zeichnen
eigentlich für den meshviewer nur als Abfallprodukt wegen den routeranleitungen ^^

(geht mir auf den sack das es meist überall nur die tp-link lästigen Anleitungen gibt und sich deswegen nette Renter ihre ubiquiti pico stations zerflashen :wink: )

ein paar Bilder habe ich mittlerweile fertig siehe:

der Rest kommt nach den Prüfungen
des Weiteren habe ich ein repo in dem die jeweiligen router fertig gehashed sind :smile:

die Idee für die Verwendung von hashes und dessen Implementierung zur Einbindung der Bilder geht auf sheogorath zurück
besten dank dafür

er hat mir auch eine webseite erstellt um die restlichen komfortabel zu hassen:
https://meshdata.shivering-isles.com

im Grunde trägt man dort den Namen den router ein wie er im meshviewer/hopGlass
angezeigt wird ein und das script im Hintergrund erstellt den hash

diesen dann als name angeben + svg what ever und das Bild wird geladen

Sieht dann bspw so aus:

hab grade keinen aktuellen screenshot
da die clientsPerMesh grade der absolute Brainfuck ist
(die load avg ist mittlerweile auch sauber in HopGlass ebenso offline since datum :wink:

Mesh per client sprengt zur zeit den Browser wenn die meshes zu groß werden :-1: :-1: :-1:

ich erstelle die Grafiken in affinity Designer prinzipiell als Vector basierte Grafiken
da die Rechtsabteilung von tp-link mir nicht mit letzter Gewissheit sagen konnte unter welcher Lizenz ihre Produktbilder stehen :-/
von daher zeichne ich alle neu da bin ich dann relativ auf der sicheren Seite :wink:

Wie gesagt die Übersicht gibt im wiki bei den routeranleitungen
Zur zeit bin ich bei dem tplink 860 re danach kommt der 1043 V1

Zur Einbindung:
die nötigen commits zusammensuchen :smiley:
und dann nach readme


einbinden
Über die Platzierung und größe wird noch diskutiert

Die Lizenz der Bilder ist

Die Bilder erstelle ich dafür genutzt zu werden und unterliegen keiner Einschränkung

werde die Quelldateien später noch hochladen als standard affinity designer + export nach illustrator (keine Garantie
für Kompatibilität ) + svg png jpg what ever :wink:

Der Plan für übernächste Woche ist aber erstmal alle mods für meshviewer für hopGlass bereit zu stellen …

hey http://dev.meshviewer.net/#!v:m;n:60e327b79544 hat mal durchgeladen :smiley:

Da bastel ich grade an HopGlass (dort ist die load avg schon gefixed (wird rot ab 1.0 )) und offline since

mit datum und Uhrzeit ist da auch schon mit drin / beides auf Github zu finden

edit:
die source der bildateien sind im Ordner picsource


#53

Gute Arbeit! Ich freue mich auf die PRs! Ich war schon versucht das Zeug selber in den HopGlass reinzufummeln…


#54

Ich habe die Bilder mal übernommen für unsere Firmware Seite in Kiel mit einem kleinen script

Hast du noch mehr Bilder?
Ev. kannst du die als PR in unserem Git einpflegen?

Schön wäre auch, wenn du die noch nicht fertigen einfach aus den Fotos mit einem Filter in Zeichnungen verwandelst, z.B. hiermit. Dazu müssten die Bilder aus deiner Wiki Seite aber in das git übernommen werden mit einheitlichen Namen, die man generieren kann aus den Modell namen.


#55

Hab das mit dem scm-File nicht hinbekommen, aber habe in Gimp einen Filter gefunden, damit hab ich mal dies hier erreicht:


#56

Ich gucke mir das mal an…

Edit:
Ich sehe keinen Weg daran vorbei, die Sachen nachzuzeichnen. Und dann direkt als SVG.
@danielkrah mich stören noch die JPGs. Das ist lossy und die Transparenz ist nicht einheitlich…


#57

sind normalerweise auch als svg dabei

wegen der transparenz im Hopglass/meshviewer


#58

PNG kann auch Tranzparenz und ist Lossless. Wozu denn überhaupt Pixelbilder? Und ich würde nur den Hintergrund transparent machen und nicht die Router ansich.


#59

@danielkrah: Ich habe die neuen Bilder eingebaut in unserer Freifunk Nord Seite: Freifunk Nord

(Ich fand das alte 841er Bild übrigens besser, habs beibehalten)

Ein paar fehlen noch, vielleicht hast du ja noch mal Zeit :slight_smile:


#60

Ich will schon die ganze Zeit Stand 2015.1.2 fertig bekommen / nur ist eben die Zeit knappes Gut :-/

Die 841er hatte ich neu gemacht da Fehler bei den anzeige-leds waren und die Bilder gerastert waren und somit 200KB groß waren