Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Grundsätzlich ist es bei Work-in-Progress so: man nicht generisch sagen, wann Bug-Meldungen stören und ab wann sie hilfreich sind
Im Ernst: das hängt ganz von der Situation ab:
Beim Planet-Design wäre es z.Zt. nicht hilfreich, da bin ich aktiv dran (deswegen hab ich's auch noch nicht öffentlich bekannt gemacht, dass es das gibt). Auch bei den 3D-Seiten ist's noch so rudimentär, dass es eher nicht hilft. Bei 2D schon eher. Bei lange bestehenden Widgets wäre es sehr hilfreich: Da Pages (und im Grunde auch Groups) schon länger im Grunde als stabil gelten, ist hier dieser Report absolut angebracht.
Wie kann man das als Nicht-SVN-Log-Leser wissen? Ich weiß es nicht.
Daher finde ich einen Bug-Report zu viel besser als einen zu wenig - notfalls schreibe ich schon, dass das erst später ansteht.
Richtig wichtig werden Bug-Reporst zu einer späteren Phase, dann wenn der Code sich stabilisiert und wir nahe an ein Release kommen. Dann gibt's aber normalerweise auch einen Aufruf jetzt zu testen und alles zu melden.
mal ne Frage zu solchen "work-in-progress" features: Willst Du dazu gleich Meldungen haben? Ich hatte das auch gesehen, aber dachte einfach, Du bist ja noch dran, deswegen hab ich nichts gesagt, sondern beim page- und group-widget einfach ein if spendiert. Ich dachte, wenn gleich einer sagt "das geht nicht" bist Du eher genervt...
Also - wenn Du das nachschaust, bitte auch bei <group>. Beide sind so generisch programmiert, dass sie immer nur widgets als children erwarten, und wenn keines gefunden wird, wird "unknown.js" eingebunden.
definiert. Ich hab leider gerade keine Zeit, weiter zugucken, was das für Konsequenzen hat, wenn man das einbindet aber das Element grösser ist. Sobald man dem "inneren" Element jedenfalls diese Klasse gibt, funktioniert colspan auch ohne rowspan. Nimmt man sie weg, wirds wieder zu schmal.
Gerade wollte ich die Syntax so anpassen, dass colspan/rowspan im Sub-Element <layout> stecken sollte:
[...]
Beim rowspan passt das auch - aber die colspan geht kaputt
=> Was ist da falsch?
Also so spontan hätte ich gesagt, dass muss so gehen. Ich kanns mir aber erst heute abend angucken.
In der jqclock.min.js steht 'könnte' anstatt 'Mai' im array der Monate.
Ich krieche jetzt einfach mal unter den Tisch und schäme mich, normalerweise lese ich schon, was ich committe
@Chris: schau ich mir an, aber das jqclock ist eh IMHO noch broken, solange es nicht ohne Widget in der config in der Statusbar funktioniert (wo ich es gerne hätte)
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: