CometVisu - (interner) Beta-Test

[StefanW]

Sind wir nicht derzeit im Feature-Freeze?

und Feature Requests für was neues gehört im Tracker auf SF angelegt.

[greentux]

Stefan, ich habe den Thread gelesen, die Doku im Wiki und die demo.xml Damit hat man ja fast alle Infos. Den JS Code kann ich mir leider nicht so recht anschauen... Daher fragte ich erst nach, obs das nicht doch gibt. Am End gibts da ein Attribut und schwups ist das schon da. Aber ja, ich werds in den tracker packen.

[StefanW]

Aber ja, ich werds in den tracker packen.

Yeah, und schon ist es angelegt

[Chris M.]

Stefan, ich habe den Thread gelesen, die Doku im Wiki und die demo.xml Damit hat man ja fast alle Infos. Den JS Code kann ich mir leider nicht so recht anschauen...

Die Doku sollte (hm...) immer dem Stand des Codes entsprechen...

Aber hier kann ich sagen, dass es das noch nicht gibt. Der Grundidee nach hat jedes Widget nämlich nur eine GA, so wie bei anderen KNX-Teilnehmern auch (vgl. "eine Taste").

Klar gibt es ausnahmen wie den ColorChosser, aber da gilt das dann halt auf einem etwas abstrakterem Kontext.

Eine Lösung sind die neu eingeführten Gruppen, die zumindest die Zugehörigkeit der Werte zeigt.
Vom Platzbedarf dürfte dies Dich jedoch nicht zufrieden stellen...

Was ich mir auch schon ein paar mal gedacht habe, wären platzsparende "Status-LEDs"... So dass ich alle Fenster-Stati in zwei Zeilen sehe, o.ä.

Hier wird es v.a. wenn die Text-Visu zur 2D-Visu erweitert wird, weitergehen. Die Text-Visu ist im Grunde nämlich nur ein Proof-of-Concept um möglichst schnell was zeigen zu können und mit minimalem Aufwand eine grundlegende Visu hin zu bekommen.
Bei der 2D (und 3D) Visu wird man dann die Widgets in der Größe verändern und frei platzieren können.

[greentux]

Der Doku fehlen im Moment Einträge zu "group" und zu "format".
Ich würde das gern ergänzen, kann aber wie gesagt nicht so recht im js code durchsteigen.
Das scheint mir ja auch auf mehrere Dateien verteilt. Wenn man mir also irgendwie das extrahieren könnte... doxygen wäre auch ne nette Variante.

[greentux]

komisches vom Editor

Nachdem ich händisch die xml geschrieben hatte, habe ich dann mal den Editor aufgemacht. Der hat dann aus meiner xml sowas hier gemacht:

 <page name="Overview">
    <line/>
    <text align="center">Welcome to the home!</text>
    <line/>
    <group>

      Temp Aussen
      3/4/51


      Luftfeuchte Aussen
      3/4/52

    </group>
    <info format="%02.1f °C">
      <label>Temp Aussen</label>
      <address transform="DPT:9.001" readonly="true" type="">3/4/51</address>
    </info>
    <info format="%02.1f %rel">
      <label>Luftfeuchte Aussen</label>
      <address transform="DPT:5.001" readonly="true" type="">3/4/52</address>
    </info>

Was bedeuten die Texte gleich nach dem <group> ? Die hat der Editor hinzugefügt. Bei mir ging es gleich mit den info Elementen weiter...

[Chris M.]

doxygen wäre auch ne nette Variante.

Es gibt wohl ein Kommentar-Format für JS das sich gut für automatische Dokus verwenden lässt und das - fast noch wichtiger - den JS-Komprimierern erheblich bei der Arbeit hilft.

Leider hatte ich da noch keine Zeit einzusteigen, aber es wäre durchaus Ziel das auch hier einzuführen.

Eine End-User Doku wie hier gerade benötigt, wird da aber wohl nicht herausfallen...

Nachdem ich händisch die xml geschrieben hatte, habe ich dann mal den Editor aufgemacht. Der hat dann aus meiner xml sowas hier gemacht:

 <page name="Overview">
    <line/>
    <text align="center">Welcome to the home!</text>
    <line/>
    <group>

      Temp Aussen
      3/4/51


      Luftfeuchte Aussen
      3/4/52

    </group>

Richtig, vgl. Bug-Report https://sourceforge.net/tracker/?fun...6&atid=1251141 - das ist eines der Dinge die noch einem Release entgegen stehen.

[greentux]

Die Doku soll nur so gut sein, das derjenige, der die Userdoku erstellt, damit was anfangen kann. Irgendwie muss ja ersichtlich sein, was wie geht, ohne den Code verstehen zu müssen.
ICh nehm natürlich auch die Spec ...

[Chris M.]

Die Doku soll nur so gut sein, das derjenige, der die Userdoku erstellt, damit was anfangen kann. Irgendwie muss ja ersichtlich sein, was wie geht, ohne den Code verstehen zu müssen.
ICh nehm natürlich auch die Spec ...

Dann fasse ich mal kurz den Status-Quo zusammen:

Wir haben als Dokus:

• Das Wiki: https://sourceforge.net/apps/mediawi...metVisu/Config
  Leider etwas veraltet - hier gehört aber IMHO die Doku hin
• Im Repository die Datei: http://openautomation.svn.sourceforg...m?revision=338
  Diese Datei ist mehr Referenz als Doku, vom Stand etwas aktueller als die Wiki-Seite

Für mich als Entwickler ist entscheidend die visu_config_demo.xml (Im Browser z.B. unter http://openautomation.svn.sourceforg...l?revision=380). Hier sind alle verfügbaren Widgets in min. einer Variation enthalten.
(Mit der Seite teste ich und sie gibt Anwendern ein Beispiel)

Die wahre Quelle der Daten ist aber der Source. Wenn Du Dir das Posting #804 ansiehst, siehst Du genau die Strukturen im Code, die die Parameter verraten.

[greentux]

Die Datei im SVN habe ich auch grad gefunden, werde sie mir mal zu Gemüte führen.
Ist ALLES notwendige in dem Design structure enthalten? Also neben den Plugins natürlich. Dann wäre das noch ne gute Quelle...

Die visu_config_demo.xml ist ganz nett, da ist aber nicht herauszufinden, welche Attributes es noch gibt.

[makki]

Wo wir grade bei Feature-Freeze waren :
Das anzeigen von RSS-Feeds wär doch auch schön? (B3 Verkehr, Tagesschau-Nachrichten, knuf, ..)
(also statt z.b. hoch-volatilen Webabfragen/Regexp-Käse im HS mit einem definiertem Datenformat zu arbeiten fand ich schon immer dringend sinnvoller..)

Aber wie ists "richtig"?
Hab mal angefangen mit jFeed, aber die Mehrheit der Blogs/Kommentare sagt, das das Kernschrott ist.. Und man es besser mit einem PHP auf dem Server macht (Auswahl)
PHP habens wir ja nun, JS, nen Server auch aber es fehlt ein Schubs in die "richtigere" Richtung?
Copyright-Probleme bitte dabei mit bedenken.. Der AW muss es sich selber holen, dann sind wir alle fein raus.. (das gefällt mir an der PHP-Lösung nicht..)

Makki

[greentux]

Ich werd gleich noch nen FR für nen caldav client einstellen.

[daviid]

Das Auswerten von RSS Feeds wär durchaus praktisch zum auswerten der Anrufliste z.B. von unsrer Auerswald COmpact 5020 VOIP, ne andere Lösung scheints da nämlich unter keinen Umständen zu geben.

[Chris M.]

Ist ALLES notwendige in dem Design structure enthalten? Also neben den Plugins natürlich. Dann wäre das noch ne gute Quelle...

Ja, .../designs/structure_pure.js ist entscheident. Die *_custom.js kannst Du ignorieren.
Dazu noch die optionalen .../plugins/*/structure_plugin.js

Das anzeigen von RSS-Feeds wär doch auch schön? (B3 Verkehr, Tagesschau-Nachrichten, knuf, ..)

Gerne, aber bitte als Plugin. Da ist's mit dem Feature-Freeze auch nicht so streng

Mehr kann ich zu RSS nicht sagen, die sind bei mir immer durch Sinnlosigkeit durchgefallen. Aber wahrscheinlich hab ich was elementares übersehen...

[greentux]

Wobei: Muss so ein RSS/CalDav Reader überhaupt in die Visu? Wenn die Visu nicht Volbild läuft, können ja allerlei Widgets drumrum plaziert werden...
Ist die Visu Vollbild orientiert?

Gruß