Meshviewer Mods auf Basis v4

Ich habe mal in die Runde gefragt und ein schlagendes Argument für die Bildchen gefunden:
Öffentlichkeitsarbeit wird erleichtert, Bunte-Bildchen-Faktor wird erhöht.

Die Bildchen sollten noch zentriert sein, ein wenig kleiner und mit transparentem Hintergrund.

Könnte man sie nicht sehr transparent gestalten und den Text davor legen.

Das könnte recht schick ausschauen

2 „Gefällt mir“

Ich stelle grade auf svg um
und kleiner wurde aus Darmstadt schon angemerkt

War ja erst mal proof of concept :smiley:

war auch am überlegen die Bilder klein vor den nodenamen zu setzen

Die dinger habe ich (bis auf den PI den gabs als freie Grafik) vectorbasierend gezeichnet.

Exportiere mal die jetzigen als png mit transparenz.

bei den Anleitungen (auch nach den Prüfungen ^^)
exportiere ich die nach pdf
tp-link-tl-wdr3600-v1.pdf (116,7 KB)

In der logischen Ansicht ist die sidebar ja leicht transparent und da siehts doof aus …

Ich erstelle mal ein repo in dem ich die „gehashten“ Bilder hochlade.

2 „Gefällt mir“

wird hier das ffmap backend für nodes V1 und Graph V1 benutzt oder schon das neue? nodes V2 aus dem backend

nodes.json

{"timestamp": "2016-01-28T15:41:02", "version": 1, "nodes":

graph.json

{"version": 1, "

nodelist.json

"updated_at": "2016-01-28T15:42:02", "version": "1.0.1"}

Moin,

da eure Mods sich mitlerweile ziemlich stark vom Meshviewer unterscheiden: Könntet ihr einen neuen Namen finden, damit weniger Supportanfragen bei mir landen und evtl. auch optisch am Design klarer machen, dass es ein anderes Projekt ist?

Zur Diskussion stehen derzeit Namen wie
HopGlass, MakaIkena, Panampil bolog <g>, Maschengucker…

Ich mein das ernst. Man kann OpenSource Projekte gerne forken, aber einen eigenen Namen sollte man sich dann schon ausdenken.

1 „Gefällt mir“

Freilich, daher habe ich Dir eine Rückmeldung geben wollen, dass Deine Nachfrage durchaus angekommen ist und was der Stand ist.
Von daher vielleicht als Disclaimer: Ich meine das auch ernst.

Schade ich dachte immer das an bei open source zusammen arbeitet aber naja dann benennt man es halt um wenn keine zusammenarbeit gewünscht ist …

btw die ersten Bilder sind gehasht

:edit
ich kenne es eher anders rum das die patches nicht upstream kommen

1 „Gefällt mir“

Ich denke ich werde den fork einfach umbenennen und mit den PRs aufhören. Inzwischen habe ich die Hoffnung aufgegeben, dass ich noch eine Antwort bekomme.

1 „Gefällt mir“

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?

4 „Gefällt mir“

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

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.

1 „Gefällt mir“

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.

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?

1 „Gefällt mir“

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

„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.

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

2 „Gefällt mir“

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