[PATCH v4 1/1] Add Leaflet-Map Position selector

Tobias Klaus tk+ff at meskal.net
Di Jan 26 20:09:20 CET 2016


Hallo delphiN,

schön, dass auch du dich am Webfrontend beteiligen möchtest.

On Dienstag, 26. Januar 2016 13:32:28 CET delphiN wrote:
> Am 26.01.2016 13:04, schrieb Tobias Klaus:
> > Vielen Dank Dominik, dass du dich so auf die Weboberfläche stürzt.
> 
> Auch von mir vielen Dank! Dank auch an Tim, der schonmal einen
> Grundstein gelegt hat. Hab mir das UI mal angeschaut und denke, dass
> dort noch sehr viel zu tun ist. Auch ich denke mit pure.css fahren wir
> hier für den Anfang sehr gut!
> 
> Ich werde mir die Web-Oberfläche in nächster Zeit auch mal vornehem
> und würde gern verhindern, dass wir Arbeit doppelt machen.
Ich denke am einfachsten wäre es hier einfach mal zu skizzieren was du so vor 
hast. Jeder der an der Entwicklung beteiligt ist kann sich dann damit 
abstimmen oder Anmerkungen machen. Damit könnte man doppelte Arbeit sparen und 
schon im Vorfeld einen entsprechenden Austausch mit den Aktiven pflegen.

> Vielleicht wäre es eine gute Idee die Web-UI in ein eigenes Repository
> auszulagern und in die Firmware z.B. über einen feed einzubinden!?
Das aktuelle Web-UI ist integraler Bestandteil der aktuell ziemlich 
tiefgreifenden Weiterentwicklung der Firmware selbst, beispielsweise was den 
dezentralen Umgang mit Hoods und Knotendaten angeht. Ich denke nicht, dass es 
Sinn macht das hier zu trennen.

> Dann wäre es einfacher die Feature-Wünsche, Bug usw. getrennt von den
> Firmware-Internals zu verwalten.
Wie schon gesagt, macht eine solche Trennung eigentlich keinen Sinn, 
einerseits brauchen wir meines Erachtens nicht noch einen Kanal und nicht noch 
ein Repository, andererseits sind die "Internals" eben doch recht eng 
verknüpft. Auch wenn es mal andere Oberflächen geben wird(siehe Kommentar 
unten) wird die aktuelle Weboberfläche erstmal sowas wie eine 
Referenzimplementierung sein.
Weshalb Feature-Requests und Bugreports für die Weboberfläche getrennt von 
denen für die Firmware verwaltet werden sollten erschließt sich mir auch nicht 
so recht. Du hast recht, dass es schön wäre einen Bugtracker zu haben, der 
sich gut in den etablierten Arbeitsstil integrieren lässt. Diese Wünsche 
wurden schon öfters geäußert und auch schon öfter besprochen. Zuletzt 
beispielsweise beim Treffen in Nürnberg.Soweit ich weiß war der Konsens sich 
entsprechende Lösungen anzusehen(Flo wollte beispielsweise mit giblab 
experimentieren) und das weiter voranzutreiben. Meiner Meinung(ich meine mich 
auch an keinen größeren Widerspruch erinnern zu können, kann das aber nicht 
als Konsens wiedergeben) nach sollte der Hauptanspruch für einen solchen 
Bugtracker sein, sich ebenfalls in den etablierten Arbeitsfluss einzugliedern.


> Außerdem wird das sicherlich nicht
> die einzige UI-Implementierung bleiben.
Das klingt, als würdest du eine zusätzliche Implementierung planen? Das 
widerspricht zwar etwas dem Gedanken doppelte Arbeit zu vermeiden, aber es 
spricht natürlich auch nichts dagegen. Auch hier wäre natürlich ganz 
interessant, mehr über deine Pläne zu erfahren.

Grüße
Tobias

> delphiN
> 
> --
> Freifunk-Franken, Förderverein Freie Netzwerke e.V.
> eMail: freifunk at wunschik.net
> XMPP : delphiN at jabber.ccc.de





Mehr Informationen über die Mailingliste franken-dev