Freetz Design

[Haembi]

ist ja gut, antworte mal nicht so pampig >_> Ich habe nur mal etwas angefragt o.o

 

[TimCedric]

Du vergisst dabie, dass das Ganze auf einer AVM-öOberfläche basiert. Hast du dir den grottigen Code mal angeschaut? Da wird so ziemlich alles in Javascript gemacht, wieso sollte Freetz dann darauf verzichten, wenn einige der Konigurationen eben dies sowieso vorraussetzen?

weil es Freetz ist und nicht avm

 

[Silent-Tears]

Irrtum. Der Router funktioniert nur einigermassen, wenn man AVM-Komponenten übriglässt und diese auch darüber konfiguriert.
Somit ist die Voraussetzung JS sowieso gegeben. Wieso sollte man sich also darum scheren, ob jemand mit Lynx auf die Kiste geht und eh nichts machen kann ausser den Freetz-Sachen?

 

[ao]

Ich würde die Sache so pragmatisch wie möglich angehen:
Wenn JS die Benutzung vereinfacht und z.T. sogar nötig ist (ohne größere Klimmzüge machen zu müssen), dann sollte auch (weiterhin) JS in Freetz angewandt werden. So wenig wie möglich, aber so viel wie nötig.

Ich zitiere mal aus der aktuellen Freetz roadmap:

Freetz Release 1.1 (Kernel 2.6)
Planned features for freetz-1.1 (more to be discussed by the developers)

• restructure web interface
• restructure patch-system
• integrate new kernel sources
• maybe new hotplug chain by johnbock?
• support for new 7270 v3 (16MB Flash)
• small enhancements of package managing

Feature freeze for this milestone is currently planned for August-October.

Bemühungen für eine Restrukturierung der Weboberfläche (ist damit denn überhautp schon ein Redesign gemeint?) sollten im Falle eines Redesigns gemeinsam bestritten werden und vorher abgestimmt sein. Sonst wird nachher alles verkompliziert.

 

[bodega]

JS ist einfach schneller und lässt sich besser umsetzen.
Berechnungen (z.B. Konfig parsen) werden am Client-PC durchgeführt und nicht mehr auf der Box. Bei der dtmfbox mache ich das bereits so und es ist schneller, als alles auf der Box durchzuführen.

Vielleicht bekommt man das auch performant mit Shellskripten hin, jedoch ist der Aufwand viel größer. Warum also nicht das nutzen, was jeder Browser bereits hergibt.

 

[yazoo83]

JavaScript? >_> Irgendwie finde ich, passt JavaScript nicht wirklich in eine Routeroberfläche. Klar, man kann hübsche dynamische Sachen machen, nur ich finde eine Routeroberfläche sollte eher statisch sein.

Dem kann ich so wie es hier steht nur indirekt zustimmen.
Zugegeben, das AVM Interface ist milde ausgedrückt etwa nennen wir es einfach mal katastrophal, aber es gibt da schon recht gute Ansätze irgendwie.
Was mich von vornherein stört ist die Geschichte mit dem Pseudo-Frame direkt am Anfang wenn man http://fritz.box aufruft

Ganz ohne JavaScript geht es aber einfach nicht. Ich habe hier einen "Noname" SiteCom Billig Router vor mir. Ein ganz einfaches Gerät was nichts anderes kann als ISP-Daten annehmen und anwählen. Selbst dieses Teil kommt im Webinterface nicht ohne Javascript aus!

Aber dennoch: AVM-Zeug is voll mit JS. Und Teile der Konfiguration ist nur über AVM-Gedöns machbar. Somit ist JS im Browser voraussetzung. Punktum.

Stimmt. Ein wenig abspecken könnte das Interface auch meiner Meinung nach.
Solange aber kein Ajax mit dazu kommt ist mir das egal, so wie es ist funktioniert alles bestens (Design wäre das einzigste was man noch bearbeiten könnte)

 

[Haembi]

Solange aber kein Ajax mit dazu kommt ist mir das egal, so wie es ist funktioniert alles bestens (Design wäre das einzigste was man noch bearbeiten könnte)

Wieso soll kein Ajax genutzt werden? Das fände ich um einiges nützlicher als KlickBunti (Ausklappmenü und ähnliche scherze)

 

[McNetic]

Bemühungen für eine Restrukturierung der Weboberfläche (ist damit denn überhautp schon ein Redesign gemeint?) sollten im Falle eines Redesigns gemeinsam bestritten werden und vorher abgestimmt sein. Sonst wird nachher alles verkompliziert.

Bei dem Punkt in der Roadmap geht es im Wesentlichen um zwei Dinge:

1. Änderung der HTML-Struktur der Oberfläche (wie in meinem obigen Beitrag bereits geschrieben, XHTML-Konformität und komplett gekapseltes Design per CSS, was dann modulare Themes erlaubt)
2. Anpassung der logischen Seitenstruktur, wobei die einzelnen Menüpunkte in Zukunft thematisch statt wie bisher funktional angeordnet werden sollen; die Menütiefe soll dabei auf 3 Ebenen erweitert werden (wobei die dritte im Wesentlichen für Paketunterkonfigurationsseiten gedacht ist).

Die beiden Punkte sind prinzipiell voneinander komplett unabhängig (bis auf die Sache mit der 3. Ebene, die bei beiden zu berücksichtigen ist) und sind soweit unter den Entwicklern schon abgesprochen. Und wie schon erwähnt, bin ich so wie es aussieht dafür zuständig, das umzusetzen bzw. die Umsetzung einzupflegen. Kritik, Vorschläge usw. sind natürlich gerne gesehen, und ich freue mich auch, wenn jemand einfach einen Teil der Arbeit übernimmt und z.B. an den Style Sheets arbeitet.

 

[GuruHacker]

Ich habe nach der readme.txt Die dateien überschrieben, und dann mit Make bauen lassen.

Nun kommt immer diese Fehlermeldung, und ich weiß einfach nicht wie ich damit umgehen soll:

index.cgi: .: line 1: can't open /mod/etc/conf/mod.cfg

Ist das jetzt ein Bug, oder irgend ein anderes Problem?

 

[franzb]

Optik ist vielversprechend. Nur funktioniert das bei mir leider nicht. Kompilieren passt, jedoch nach dem Flashen wird die Freetz-Oberfläche nicht angezeigt, Frame bleibt schlicht leer.

Franz

 

[GuruHacker]

Kommt bei dir auch villeicht die gleiche Fehlermeldung wie bei mir?

Die ist bei mir immernoch - obwohl die datei Exestiert

 

[franzb]

Kommt bei dir auch villeicht die gleiche Fehlermeldung wie bei mir?

Nein, für einen Augenblick wird "Freetz ... Redirect" (oder ähnlich) angezeigt und dann herrscht Funkstille.

 

[Loomes]

@franzb
Jo so ist das bei mir auch so im FF
Im IE kommt auch noch die htaccess und dann "Die Seite kann nicht angezeigt werden"

Edit: Fehler gefunden. Die libmodcgi wurde nicht unix konform abgespeichert sondern in einem Dos Format. Somit ist sie voll mit Sonderzeichen die da nicht hingehöhren
Habe mal eine richtige Version angehängt mit welcher die Web Oberfläche dann funktioniert.

So habs mir jetzt mal ein wenig angesehen und finde es wirklich klasse
Es macht einen modernen und vorallem sehr schicken Eindruck. Ich hoffe das der Ersteller an dieser Sache dranbleibt. Es ist wie ich finde eine echte Alternative zu dem original Freetz Aussehen.

 

[franzb]

Fehler gefunden. Die libmodcgi wurde nicht unix konform abgespeichert sondern in einem Dos Format. Somit ist sie voll mit Sonderzeichen die da nicht hingehöhren
Habe mal eine richtige Version angehängt mit welcher die Web Oberfläche dann funktioniert.

Ah, fein, danke. Werde das gleich mal ausprobieren.

Edit: Das wars. Funktioniert jetzt einwandfrei.

@TimCedric: Vielen Dank!

 

[cuma]

Ich finde diese Bars sehen hübscher aus. Ausserdem wird das Cache noch angezeigt: klick

Hier noch ein aktuelles Bild davon:

 

[GuruHacker]

das mitm chache kann mann ja einbauen, aber sonst finde ich, das Graue "bars" nicht zum gesamtkonzept passen würden.

Mahlzeit und Prost!

 

[cuma]

Orange ist aber schon ein bisschen stechend. Am besten stellt das jeder nach Belieben ein. Mit ging es aber um die der Bars selbst

 

[TimCedric]

Habe es mal im download ergänzt

 

[GuruHacker]

So nach dem Libmod patch läuft alles... Nur es muss eine Korrektur für das dynamische anpassen an den Bildschirm gemacht werden. Ich weis nicht, wo ich das korregieren soll...

 

[TimCedric]

Such mal in der libmodcgi.sh nach width="960" und ersetze es mit width="$_cgi_width"
ob das hilft weiß ich nicht aber ein Versuch ist es wert