WebIF - Dateiname des geflashten Images

[hermann72pb]

@Andreas: Verstehe ich es richtig, dass du überall alles in lowercase übersetzt? Das wäre zu schade! Ich hatte damals EXTRA für Libraries eine Sonderbehandlung gemacht. Denn, wenn du uClibs oder Ähnliches als lowercase anzeigst, sieht es nicht sonderlich gut aus.

MfG

 

[colonia27]

Hermann, so siehts jetzt nach den aktuellsten Änderungen aus.

 

[siri38]

...

@buehmann .

Danke ! Funktioniert bei mir auch .

 

[hermann72pb]

@siri38: Hab inzwischen selbst rausgefunden. Stand auch im ChangeLog dazu, dass es gerade andersum begründet war, warum es nicht ging.

Mir gefällt die neue Breitenbehandlung nicht besonders.
@buehmann: Ich verstehe schon, dass du gerne überall auf automatische Breitenbehandlung und %-Angaben umsteigen willst. Aber es funktioniert eben nicht immer zuverlässig und richtig.

Du bist im Fenster für die Variablendarstellung von textarea-Tag zum pre-tag übergegangen. War das wirklich notwendig? In meinem Fall (s. Bilder) würde ich eher mit einer gleichmäßigen Breite zufrieden sein und nur in einem Falle für diese konkrete Variable (s. Bild) horizontal scrollen wollen, als so eine stufige Anordnung zu haben. Vor allem, es trägt in diesem Fall gar nicht der besseren Darstellung bei.

Ich bin kein wirklicher Experte in Sachen html- oder Shell-Kodierung und bin dir für die Korrekturen sehr dankbar, aber sei bitte so lieb uns auch die Motivationen zu deinen Veränderungen zu verraten. Vielleicht stehe ich nur alleine auf dem Schlauch, wenn ich Einiges nicht verstehe.

MfG

 

[cuma]

Motivation ist wohl (Geschwindgkeits)-Optimierung und Vereinfachung. Laut Roadmap "restructure web interface"

 

[buehmann]

Hallo Herrmann,

erstmal sorry, dass ich ohne Vorwarnung und Absprache dein Baby umgekrempelt habe. Meine Motivation ist momentan dreierlei: Ich strebe an, dass das Webinterface schnell ist (oder sagen wir lieber: nicht unnötig langsam), dass Inhalt und Formatierung besser getrennt sind als jetzt und dass der Code, der die Seiten erzeugt, übersichtlich und gut verständlich ist.

@Andreas: Verstehe ich es richtig, dass du überall alles in lowercase übersetzt

in der ersten Überarbeitung ja; seit gestern, als ich den Sinn erkannt habe, ist die Sonderbehandlung wieder drin und die Module und Libs werden so belassen, wie sie sind. Der Rest ist klein.

Mir gefällt die neue Breitenbehandlung nicht besonders.

Ich gebe dir recht. In deinem Fall sieht das ganz besonders hässlich aus. Sorry, das habe ich so noch nicht gesehen (bzw. vorausgesehen). Ich werde mich heute um eine Lösung kümmern.

Ich verstehe schon, dass du gerne überall auf automatische Breitenbehandlung und %-Angaben umsteigen willst. Aber es funktioniert eben nicht immer zuverlässig und richtig.

Richtig, die ganze _cgi_width-Rechnerei und die hartkodierten Längenangaben sind mir ein Dorn im Auge. Sie (werden) verhindern, dass wir das Webinterface einfach auf einen neuen Stil umstellen können. Deswegen mache ich in den letzten Tagen erste zögerliche Schritte des Aufräumens auch in dieser Richtung. Dabei bin ich aber immer darauf bedacht, dass für den Moment alles weiterhin so aussieht wie bisher.

Du bist im Fenster für die Variablendarstellung von textarea-Tag zum pre-tag übergegangen.

Auf allen anderen Seiten wird für solche Readonly-Log-/Datei-Ausgaben das pre-Tag benutzt. Deswegen schien mir eine Vereinheitlichung angebracht. Vor allem sah die ausgegraute Textarea extrem anders aus.

In meinem Fall (s. Bilder) würde ich eher mit einer gleichmäßigen Breite zufrieden sein

Wie gesagt, ich schaue mir das gleich an. Und ich bin zuversichtlich, dass die gleichmäßige Breite auch mit pre und ohne explizite Breitenangaben machbar ist.

Vielleicht stehe ich nur alleine auf dem Schlauch, wenn ich Einiges nicht verstehe.

Wenn du oder jemand anderes Fragen hat, wie die Erzeugung der Info-Tabelle jetzt intern funktioniert, helfe ich euch gerne weiter. Am einfachsten ist es zu überblicken, wenn man die auskommentierte "echo ... preprocess..."-Zeile aktiviert, so dass man den Zwischenzustand der beiden Verarbeitungsschritte sieht.

Viele Grüße,

Andreas

 

[hermann72pb]

Ok. Danke für die Aufklärung! Wenn ich irgendwo behilflich sein könnte, melde dich. Ansonsten viel Glück beim Umkrempen!
Ich hatte an einer anderen Stelle in mounted.cgi bereits ganz vorsichtig angefangen Einiges in die Stylesheets auszulagern. Ob ich das bei den beiden Info-Seiten auch benutzt hatte, weiß ich nicht mehr. Auf jeden Fall ist die Idee an sich gut alles einheitlich zu machen und möglichst per stylesheets an einer zentralen Stelle regeln. Allerdings muss man das dann konsequent machen. Und das ist viel Arbeit.
Wenn du sagst, dass "pre" eher dafür zum Einsatz kommt als "textarea", dann mach es eben mit "pre". Allerdings hatte ich mit dem vordefinierten "pre" irgendwelche Probleme damals gehabt und bin deswegen zwangsweise zu "textarea" umgestiegen, die ich vom downloader kannte. Man kann sicherlich "pre" in diesem Fall (oder sogar allgemein) per styles passend umbiegen. Einfach ist es aber nicht.
Noch ein Paar Allgemeintipps aus meinen damaligen Experimenten mit den Balken in mounted.cgi und co.:
1. Halte immer neben Firefox noch IE bereit und nach Möglichkeit als IE6 oder IE7 und dann natürlich auch IE8. Ich hatte anfangs sehr viele Ideen gehabt dies oder das so zu realisieren, wie ich wollte. Die ganzen Ideen scheiterten dann an der blöden IE-Darstellung, die noch von Version zu Version unterschiedlich ist. Klar, schreiben wir unter dem WebIF, dass es für FF optimiert ist. Man kann aber IE-Benutzer nicht komplett außer Acht lassen und für die eine wenigstens halbwegs funktionierende darstellung anbieten.
2. Versuch bitte alles, was es geht in die style-sheets auszulagern. Das tust du bereits. Nur nicht nachlassen.
3. Versuche bitte von dem klassichen Tabellen-Missbrauch (tr-td-Syndrom) für das Layout weg zu gehen und möglichst div-Kontainer mit unterschiedlichen Layer dafür zu benutzen. Es geht noch nicht überall und nicht immer, man sollte es aber anstreben. Bei der mounted.cgi hätte ich es gerne komplett mit div-s realisiert, war mir aber leider nicht gelungen.
4. Die Breiten-Rechnerei in den cgi-Skripten finde ich nicht unbedingt als nachteilig. Dafür sind es auch cgi-Skripte. Klar, sollte man versuchen Breitenangaben in % zu machen, ich würde dennoch nicht ganz auf die Breitenvariable verzichten.

Und wie gesagt: Respekt, dass du dir so viel Mühe machst unsere alten Sünden hier im Projekt gerade zu ziehen und zu einem gemeinsamen Nenner zu bringen! Dass dabei nicht alles sofort funktionieren wird ist klar. Deswegen bist du auf Feedback angewiesen. Dafür wäre es meiner Meinung nach angebracht so einen Meckerthread zu WebIF-Änderungen zu erstellen, wo sich jeder mit konkreten Hinweisen und Bildern melden könnte. Oder wir belassen es wie jetzt bei den konkreten Paketen/Webseiten und diskutieren es getrennt.

MfG

 

[buehmann]

Hi,

1. Halte immer neben Firefox noch IE bereit und nach Möglichkeit als IE6 oder IE7 und dann natürlich auch IE8.

momentan habe ich den IE8 da (neben Firefox und Google Chrome) und schalte den auch mal um in den "Kompatibilitätsmodus". Soweit ich weiß (und da dabei viel kaputt geht), simuliert er viele Fehler der älteren Versionen (bzw. es ist genau die alte Rendering-Engine, die dann eingesetzt wird).

Ich hatte anfangs sehr viele Ideen gehabt dies oder das so zu realisieren, wie ich wollte. Die ganzen Ideen scheiterten dann an der blöden IE-Darstellung

Kenne ich zu gut. Die erste Überarbeitung der Statusbalken war eine Liste (ul/li), die per CSS tabellenartig dargestellt wurde. Dem IE zuliebe ist es jetzt wieder auch im Quelltext eine Tabelle ...

Versuch bitte alles, was es geht in die style-sheets auszulagern.

Ja, das ist mein übergeordnetes Ziel.

Versuche bitte von dem klassichen Tabellen-Missbrauch (tr-td-Syndrom) für das Layout weg zu gehen

Das versteht sich von selbst.

Klar, sollte man versuchen Breitenangaben in % zu machen, ich würde dennoch nicht ganz auf die Breitenvariable verzichten.

Klar, die einstellbare Breite auf die Wünsche des Benutzers ist auch eine gute Sache. Nur wenn an allen Ecken und Enden 278,34 Pixel von der Breite abgezogen werden, weil man weiß, dass das zu irgendeinem Zeitpunkt mal die Breite des Menüs plus Abstände plus irgendwas war, dann sollte das im Code beseitigt werden, soweit es mit vertretbarem Aufwand möglich ist.

Gruß,

Andreas

 

[Silent-Tears]

Hallo Andreas,

Dabei bin ich aber immer darauf bedacht, dass für den Moment alles weiterhin so aussieht wie bisher.

Ich glaube bei deinem Vorhaben wäre es sinnvoller, da einen radikalen "Cut" zu machen und auch in Kauf zu nehmen, dass etwas nicht passt eine Weile. Zumindest sofern du in der Lage bist, das Problem kontinuierlich anzugehen und dann auch fertigzustellen, eben auch auf die Gefahr hin, dass das Webinterface ein paar Tage nicht sauber läuft. Wenn du dabe iUnterstützung benötigst, Vorschläge, Styles, etc dann mach doch einfach nen Thread hier auf, oder auch ein Ticket, da findet sich sicherlich für alles eine Lösung.

Nur wird eben das "zaghafte" Stück für Stück ergänzen, Fehler rausfinden und beseitigen das gesamte Webinterface auf Dauer nicht besser machen, sondern simpel weitere mögliche Fehlerquellen erzeugen, dadurch, dass man eben auf so vieles inzwischen Rücksicht nehmen muss. Eventuell sollte man dafür auch einen temporären Brach aufmachen, und dann entsprechend zurückmergen, wenn es einigermassen rund läuft?

Btw gab es von McNetic schon einmal einen Ansatz, das Webinterface umzustrukturieren und entsprechend auf Stylesheets und ähnliches umzusetzen. Vllt. kannst du mit seinen Sachen etwas anfangen? Soweit ich weiss, hat er nen Patch angehangen, bevor ihn die Zeitfreiheit eingeholt hat.


LG

Lars

 

[buehmann]

Hi Lars,

Ich glaube bei deinem Vorhaben wäre es sinnvoller, da einen radikalen "Cut" zu machen und auch in Kauf zu nehmen, dass etwas nicht passt eine Weile.

ja, das wird zwangsläufig so kommen müssen, wenn größere Umbauten anstehen. Schon allein deswegen, weil man nicht 50+ Pakete mit ihren Webseiten im Auge behalten kann.

Eventuell sollte man dafür auch einen temporären Branch aufmachen, und dann entsprechend zurückmergen, wenn es einigermassen rund läuft?

Ja, das ist eine gute Idee und das habe ich schon im Hinterkopf. Vorher wollte ich einige Aufräumarbeiten im Webinterface-Code machen, die unabhängig vom großen Cut gemacht werden können, so dass man nicht zuviel davon in den Branch schleppt und sich dort aufs Eigentliche konzentrieren kann. Außerdem habe ich so nochmal einen Überblick bekommen, wie das Webinterface funktioniert.

Ich werde bald mal ein Ticket für den großen Umbau aufmachen und dort die generellen Ziele/Anforderungen festhalten und zur Diskussion stellen. Von dort aus könnten wir dann mit der Arbeit in einem Branch anfangen.

Soweit ich weiss, hat er nen Patch angehangen, bevor ihn die Zeitfreiheit eingeholt hat.

Weißt du, wo sich dieser Patch befindet? (Die Zeitfreiheit wird mich allerdings auch bald wieder einholen. Mal sehen, ob ich dieses Teilprojekt am Leben halten kann.)

Gruß,

Andreas

 

[buehmann]

In meinem Fall (s. Bilder) würde ich eher mit einer gleichmäßigen Breite zufrieden sein

Ich habe erst einmal aufgegeben und eine berechnete Breite gesetzt: http://trac.freetz.org/changeset/4571
Die Kombination "<fieldset> mit <pre>-Kind" verhält sich extremst eigenartig ...

Andreas

 

[hermann72pb]

Wie äußert sich die Eigenartigkeit? Was hast du da alles ausprobiert? Wobei gab es Probleme? IE oder allgemein?
Ich weiß nicht, inwieweit du mit dieser Eltern-Kind-Problematik in HTML vertraut bist. Vor allem bei Positionsangaben, prozentuellen Breiten usw. muss man da viel Beachten. Die Browser verhalten sich da auch unterschiedlich. Manchmal meinen manche Tags direkte Kinder von BODY zu sein (warum auch immer). In diesen Fällen gilt natürlich 100% bezogen auf BODY-Breite. Angeblich kann man neuerdings über styles diese Eltern-Kindern-Verhältnisse in gewissen Grenzen beeinflüßen. Klappt aber nicht immer. Man kann sogar mittlerweile INLINE-tags zu den Absatz-Tags erklären und umgekehrt. Dadurch werden Eltern-Kind-Verhältnisse möglicherweise auch beeinflusst.
Einen dicken Strich über die Rechnung bringt die Benutzung von "position:absolute" in den Styles. Dann meinen manche Tags dierekt von BODY abzustammen und richten sich auch oft danach.

Ich hatte auf jeden Fall da irgendwann mal den Überblick verloren und hatte aufgegeben. Aber da du sowieso vor hast es komplett neu anzugehen, wäre es vielleicht sinnvoll die Hauptstruktur und Verschachtelung von allen FREETZ Frames und Container in diesem Zusammenhang zu überdenken?

MfG

 

[buehmann]

Hallo,

Wie äußert sich die Eigenartigkeit? Was hast du da alles ausprobiert? Wobei gab es Probleme? IE oder allgemein?

ich habe nur in Firefox herumprobiert. Seltsam war die Breitenberechnung von fieldset und pre:

1. pre mit automatischer Breite und "overflow: auto" in div ("display: block"): pre ist so breit wie möglich innerhalb des divs, es gibt horizontale Scrollbalken für lange Zeilen.
2. fieldset ("display: block") innerhalb div: Hat auch automatisch die volle Breite
3. pre aus 1 in fieldset aus 2: pre ist viel zu breit, es gibt horizontale Scrollbalken, aber nur ganz wenig zu scrollen. Das fieldset passt sich dem pre an und ist auch viel zu breit.
4. In 3 statt fieldset/label als Container div/h1: Alle Breiten sind wie erwartet

Dadurch werden Eltern-Kind-Verhältnisse möglicherweise auch beeinflusst.

Die verqueren Verhältnisse sind mir auch aufgefallen, als ich meine Überschrift in meinem handgemachten fieldset per "position: absolute" positionieren wollte. Laut Spezifikation bedeutet das eigentlich relativ zum umgebenden Block. Firefox ist dabei allerdings ein paar Ebenen höher gehüpft.

Aber da du sowieso vor hast es komplett neu anzugehen, wäre es vielleicht sinnvoll die Hauptstruktur und Verschachtelung von allen FREETZ Frames und Container in diesem Zusammenhang zu überdenken?

Ja, auf jeden Fall.

Gruß,

Andreas

 

[hermann72pb]

Noch so ein Tipp/Beobachtung am Rande. Manchmal spielt es eine Rolle, in welchen Einheiten man redet. Vor allem bei den Schriftarten und solchen schriftbezogenen Sachen, wie textarea oder pre. Wenn du die Einheit als "pt" angibst, reagiert er manchmal komplett anders, als wenn es "px" sind, oder gar keine Einheit. Grund dafür ist vermutlich, dass bei "pt" eine Umrechnung unter Einbeziehung diversen anderen Sachen und Klient-Darstellungsinformationen erfolgt. Ich kann jetzt nicht eindeutig sagen, wann und wobei man "pt" und wobei "px" erforderlich ist. Ich persönlich versuche mich an die Regel zu halten, Schriften in "pt" einzugeben und den Rest in "px". Es mag jedoch sein, dass dies nicht ganz korrekt ist und nicht immer funktioniert. Wenn dazu noch %-Angaben kommen, dann wird das Ganze noch komplizierter.
Es geht manchmal bei diesen "pt" und "px" soweit, dass ein falscher "px" irgendwo in irgendeiner Schrift am Ende deiner Seite dein komplettes Layout durcheinander bringen kann.

MfG

 

[Silent-Tears]

Ich schlage wirklich obigen erwähnten branch vor, und dann legt ihr los
Das spart doppelte Arbeit...

 

[buehmann]

Und ihr anderen lehnt euch erst zurück und fangt dann an zu schreien, weil nichts mehr so aussieht wie vorher ... jaja ;-)

 

[Silent-Tears]

Ich mag Veränderungen, so lange sie sinnvoll sind und einen Mehrwert bieten nach Abschluss

 

[hermann72pb]

Nee Lars, Andreas hat schon Recht. Angesichts des breiteren Testegrades würde ich in diesem speziellen Fall von WebIF-Umgestaltung schon eine "Operation am offenen Herzen" (sprich direkte Veränderungen im trunk) einem abgetrennten branch bevorzugen. Wie du selber sagtest, müssen wir alle da durch, selbst wenn es schmerzhaft ist. Das Problem an den WebIF-Veränderungen liegt darin, dass du als Entwickler nicht alle Fälle nachbilden kannst und bist auf die Betatester angewiesen. Und in den meisten Fällen handelt es sich wirklich nur um Schönheitsprobleme, also keine Gefährdung der Funktion.

Lass uns doch alle wenigstens Betatester spielen und einen schnellen Feedback geben.

MfG

 

[Silent-Tears]

Soll mir auch Recht sein

 

[buehmann]

Oder so; sobald Freetz 1.2 festgezurrt und abgetrennt ist, können wir natürlich auch den Trunk verunstalten.