CometVisu - (interner) Beta-Test

[netzkind]

Auschecken ist kein Problem, auch Update nicht. Nur beim Commit mosert mein tortoise. Auch wenn ich das Projekt komplett neu auschecke und auf dem neuen Verzeichnis versuche zu arbeiten.

Ich bekomm aber auch im Browser das hier nicht geöffnet: http://openautomation.svn.sourceforg...penautomation/

("Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde.")

[netzkind]

Das einzige was sich geändert hat, ist das ich den User "Christian" als Admin hinzugefügt habe - im Rahmen der SF-Troubles bin ich nämlich wieder über meinen alten Account gestolpert...

User-ID 1024 hat aber auch einen echt hohen Nerd-Faktor

[Chris M.]

Auschecken ist kein Problem, auch Update nicht. Nur beim Commit mosert mein tortoise. Auch wenn ich das Projekt komplett neu auschecke und auf dem neuen Verzeichnis versuche zu arbeiten.

Und ein Update im frisch ausgecheckten? Nicht dass Tortoise irgendwie ein altes Passwort speichert...

Ich bekomm aber auch im Browser das hier nicht geöffnet: http://openautomation.svn.sourceforg...penautomation/

("Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde.")

Die Seite geht bei mir auch nicht. Die Seite https://openautomation.svn.sourcefor...penautomation/ auf die der SVN Client direkt zugreift dagegen schon. (Und dass bei mir das Einchecken funktioniert, wird ja hier eh schon jeder mitbekommen haben)

User-ID 1024 hat aber auch einen echt hohen Nerd-Faktor

Ja, da war ich auch sehr erstaunt als ich die ID gesehen habe, aber dann hatte ich gesehen, dass der Account ja schon über 11 Jahre alt ist... Und man beachte, dass die ID eine Zweierpotenz ist

[netzkind]

Und ein Update im frisch ausgecheckten? Nicht dass Tortoise irgendwie ein altes Passwort speichert...

Hab die Kennwörter in Tortoise schon zurückgesetzt, aber er fragt mich aktuell auch bei jedem commit 5 mal bevor er aufgibt.
svn co und svn update sind anonyme Operationen - die laufen problemlos.
Nur svn ci macht Probleme.

[netzkind]

Ich bekomm aber auch im Browser das hier nicht geöffnet: http://openautomation.svn.sourceforg...penautomation/

("Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde.")

OK, das erklärt sich: viewvc ist noch abgeschaltet.

Kann trotzdem nicht committen. Wahrscheinlich wurde ich vorrübergehend fürs SVN gesperrt weil ich vorhin wie ein doofer mein altes Kennwort probiert habe bevor mir einfiel dass Sourceforge ja grade erst angegriffen wurde und die Kennwörter resettet hat

Dann kann ich ja hier schon mal vorankündigen:
ich hab den Editor für die neue Datenstruktur wieder lauffähig gemacht. Er läuft NICHT für den Colorchooser - das Attribut "color" pro address-Element hab ich bewusst nicht umgesetzt. Ich denke da sollte man ein generischeres Attribut verwenden, da der Code für das Bearbeiten der Sub-Elemente von Widgets im Editor derzeit hartcodiert ist.

Zumindest beim Editor machen wir auch grade definitiv technische Schulden die uns beim nächsten Ändern der Datenstruktur richtig Probleme bereiten dürften. Das Maß in dem beim Editor die Strukturen hartcodiert sind, oder auch die Komplexität der Konstrukte macht den Code schwer wartbar.

Gleichzeitig werde ich in nächster Zeit weiter nicht zuverlässig (wenn überhaupt) am dringend notwendigen Refactoring oder dem Editor arbeiten können, da ich im Hochzeitsstress stecke. Wenn man die anschließenden Dankeskarten nicht berücksichtigt endet der erst im April.

Grüße,
Julian

[Chris M.]

OK, das erklärt sich: viewvc ist noch abgeschaltet.

Kann trotzdem nicht committen. Wahrscheinlich wurde ich vorrübergehend fürs SVN gesperrt weil ich vorhin wie ein doofer mein altes Kennwort probiert habe bevor mir einfiel dass Sourceforge ja grade erst angegriffen wurde und die Kennwörter resettet hat

Hoffentlich geht's morgen wieder.

Dann kann ich ja hier schon mal vorankündigen:
ich hab den Editor für die neue Datenstruktur wieder lauffähig gemacht.

Supper!

Er läuft NICHT für den Colorchooser - das Attribut "color" pro address-Element hab ich bewusst nicht umgesetzt. Ich denke da sollte man ein generischeres Attribut verwenden, da der Code für das Bearbeiten der Sub-Elemente von Widgets im Editor derzeit hartcodiert ist.

OK - was schlägst Du als Struktur hier vor? So etwas wie:

   <colorchooser>
      <label>A colorChooser</label>
      <color type="r">
        <address transform="DPT:5.001">1/2/59</address>
      </color>
      <color type="g">
        <address transform="DPT:5.001">1/2/60</address>
      </color>
      <color type="b">
        <address transform="DPT:5.001">1/2/61</address>
      </color>
    </colorchooser>

Ein Widget, dass mehrere Arten von Addressen braucht, lässt sich ja auch bei anderen Anwendungen vorstellen...

Zumindest beim Editor machen wir auch grade definitiv technische Schulden die uns beim nächsten Ändern der Datenstruktur richtig Probleme bereiten dürften. Das Maß in dem beim Editor die Strukturen hartcodiert sind, oder auch die Komplexität der Konstrukte macht den Code schwer wartbar.

Auch wenn das natürlich unbefriedigend ist, sehe ich es jetzt gerade nicht so schlimm.
Wir müssen zuerst die Struktur sauber machen und (irgend)einen Editor für diese Struktur haben. Dann können wir releasen und anschließend in Ruhe den Editor refactoren - die Anwender werden das dann nicht mehr merken, da deren Config sich nicht mehr (inkompatibel) ändert.

Gleichzeitig werde ich in nächster Zeit weiter nicht zuverlässig (wenn überhaupt) am dringend notwendigen Refactoring oder dem Editor arbeiten können, da ich im Hochzeitsstress stecke. Wenn man die anschließenden Dankeskarten nicht berücksichtigt endet der erst im April.

OK, diese Ausrede lasse ich mal gelten

[netzkind]

OK - was schlägst Du als Struktur hier vor? So etwas wie:

   <colorchooser>
      <label>A colorChooser</label>
      <color type="r">
        <address transform="DPT:5.001">1/2/59</address>
      </color>
      <color type="g">
        <address transform="DPT:5.001">1/2/60</address>
      </color>
      <color type="b">
        <address transform="DPT:5.001">1/2/61</address>
      </color>
    </colorchooser>

Ein Widget, dass mehrere Arten von Addressen braucht, lässt sich ja auch bei anderen Anwendungen vorstellen...

Bloß nicht, das macht es für den Javascript-Code noch komplizierter. Jede zusätzliche XML-Ebene im Widget macht echt richtiges Kopfzerbrechen.

Ich dachte eher an sowas:

   <colorchooser>
      <label>A colorChooser</label>
      <address transform="DPT:5.001" type="r">1/2/59</address>
      <address transform="DPT:5.001" type="g">1/2/60</address>
      <address transform="DPT:5.001" type="b">1/2/61</address>
    </colorchooser>

Das type-Attribut wäre damit ein Freifeld das man bei jeder address angeben kann - aber es wird halt nicht bei jeder ausgewertet und/oder gebraucht.

Wir müssen die Daten ja nicht nur laden/speichern, sondern vor allem im Editor auch darstellen. Da hat man die Wahl zwischen "dynamisch" und "sichtbar strukturiert". Deshalb tendiere ich dazu da Regeln vorzugeben was ein address-tag für attributes haben kann, und dann müssen sich die Plugins daran halten - oder sie sind nicht Editor-tauglich.

und anschließend in Ruhe den Editor refactoren - die Anwender werden das dann nicht mehr merken, da deren Config sich nicht mehr (inkompatibel) ändert.

Dazu fällt mir spontan ein: wir sollten eine Versions-Nummer ins XML mit aufnehmen, welches die "Release-Version" wiedergibt. So können wir Konverter in PHP schreiben damit wir auch zukünftig noch kraftvoll zubei...upgraden können ohne dass die User ihre Config verlieren.

[netzkind]

Hoffentlich geht's morgen wieder.

Chris: Ich hab dir per Mail einen Patch auf die aktuelle Revision geschickt - wenns bei dir klappt, check du es doch ein.

Um es kurz zu machen, es fehlt seit etwa drei Wochen ein wenig am Fortschritt, weil die Frage der Konfig-Datei noch nicht gelöst ist und auch die Ressourcen der Entwickler derweil auch noch mit anderen Aufgabenstellungen belegt sind.

Meine Prognose vom Januar, dass es nach meiner Einschätzung nur noch 4 bis 8 Wochen dauern kann, ist so nicht mehr zu halten. Diese Prognose bezog sich auf den Fortschritt zu diesem Zeitpunkt.

Makki kann Euch das bestätigen, es ist fast täglich ein Punkt auf der Besprechungsagenda intern, weil es hängt ihm schon zu den Ohren raus, dass ich es permanent anspreche. Aber, es liegt auch nicht nur an uns.

Die Frage des Konfig-Formates ist generell damit geklärt denke ich - bleibt bei XML, nur die Form könnte sich noch minimal ändern.

Und hoffentlich kann makki nach dem Patch wieder ein wenig besser schlafen

[Chris M.]

Bloß nicht, das macht es für den Javascript-Code noch komplizierter. Jede zusätzliche XML-Ebene im Widget macht echt richtiges Kopfzerbrechen.

Ich dachte eher an sowas:
[...]
Das type-Attribut wäre damit ein Freifeld das man bei jeder address angeben kann - aber es wird halt nicht bei jeder ausgewertet und/oder gebraucht.

OK, können wir gerne so machen.

Dazu fällt mir spontan ein: wir sollten eine Versions-Nummer ins XML mit aufnehmen, welches die "Release-Version" wiedergibt.

Das macht Sinn.

Chris: Ich hab dir per Mail einen Patch auf die aktuelle Revision geschickt - wenns bei dir klappt, check du es doch ein.

Mach ich, aber vermutlich erst morgen.

[makki]

Also ich kann commiten, habs grad mal getestet; hab nur pw-reset und beim "svn up" den neuen Key bestätigen müssen..

@Julian: mein Beileid äh Glückwunsch natürlich

Fragen nach Release-Terminen perlen an langjährigen Debianern ab wie Babyöl: es ist fertig wenns fertig ist

Makki

[netzkind]

Also ich kann commiten, habs grad mal getestet; hab nur pw-reset und beim "svn up" den neuen Key bestätigen müssen..

Na wir werden sehen
https://sourceforge.net/apps/trac/so...e/ticket/17223

Edit: oops. Falsche URL

[Chris M.]

Mach ich, aber vermutlich erst morgen.

Hab's doch gerade geschafft - aber komplett ungetestet (das kommt dann morgen... )

[makki]

Editor

Da kann ich mich ja dann auch mal nützlich machen..
Sieht alles in allem sehr gut aus

Die bekannten:
- chrome (schlimmer: = Webkit, Safari..)

Was auffiel:
- wenn man mehrere address im Widget anlegt und nicht mit GA's belegt, fliegt die Visu teilw. ab. Anwender tun sowas

Allgemein:
Die precision beim Info-Widget finde ich noch nicht so "intuitiv", bei prec. 4 macht 1°C -> 1.000 und 22.8->22.80 (schaue ich mir morgen aber mal selbst an)

Makki

[makki]

Precision

Hi,

toPrecision macht das wohl eben so, toFixed täte was ich erwartet hätte..
Zusätzliches Attribut "fixed" oder toPrecision in toFixed ändern? (ich wüsste aber nicht zuwas toPrecision gut wäre..)

Makki

[Chris M.]

aber komplett ungetestet

Jetzt läuft's endlich.
Irgendwie hatte der Browser wieder sehr aggresiv gecached