CometVisu - (interner) Beta-Test

[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

[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.

[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]

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

[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.

[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]

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

[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.")

[Chris M.]

Laut Admin-Seite (https://sourceforge.net/project/admi...roup_id=296426) bist Du Member - genau so wie immer... (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...)

Was ich auch noch hatte, war das sich anscheinend der SSH-Key von SF geändert hatte. Dem kdesvn musste ich erlauben einen neuen Key (oder war es ein nicht öffentlich zertifiziertes SSL?) zu lernen.

Was passiert denn, wenn Du in ein anderes Verzeichnis einfach mal frisch auscheckst?

[netzkind]

Jo, war mir bekannt. Kennwort hab ich geändert, habe aber dennoch keinen Zugriff aufs SVN.
Laut Projekt-Seite bin ich daran auch garnicht mehr beteiligt ... oder ich finds nicht ...

Grüße,
Julian

[Chris M.]

SourceForge hatte einen Hack, d.h. die haben zur Sicherheit alle Accounts deaktiviert und man muss sein Passwort per eMail resetten damit man wieder darf.

[netzkind]

Hab aktuell keine Schreibrechte aufs SVN - any ideas?

Julian

[Chris M.]

hab aber das Problem dass ich inzwischen mit dem ganzen restlichen Code des "Editors" nicht mehr wirklich einverstanden bin (it's a hack job)

Ha, das kenne ich!

Könntest Du nicht den Hack-Job bei minimalem Aufwand noch so weit bringen, dass der Editor wieder läuft, wir ein Release machen und Du dann genug Muße hast den auf Wunsch-Stand zu bringen?

Wir hätten dann nämlich nicht nur ein Release, sondern auch einen funktionsfähigen Editor beim Weiterentwickeln des Restes

[netzkind]

kannst Du mal bisschen Feedback über den Stand geben?

Im Westen nichts neues.
Ich bin mit meinem Entwicklungsstand ein winzigkleines Stückchen weitergekommen, hab aber das Problem dass ich inzwischen mit dem ganzen restlichen Code des "Editors" nicht mehr wirklich einverstanden bin (it's a hack job) und jetzt bei der Überlegung das alles zu refactoren steckengeblieben bin

Eine Timeline kann ich dadurch jetzt nicht mehr vorweisen ...

Grüße,
Julian

[Chris M.]

Gut das wir drüber geredet haben, ich schau mir das bei nächster Gelegenheit mal an ob sich das so umsetzen lässt

Hallo Julian, kannst Du mal bisschen Feedback über den Stand geben?