CometVisu - (interner) Beta-Test

[Bodo]

Hoi

Hmmm, irgendwas ist anders.
Entweder alle sind in den Skiferien oder die CometVisu ist fertig?

[makki]

Kannst Du mir da noch mal den Source schicken?

Na, deswegen ist der schmutzige PoC inkl. js (man darf auch ohne Header GPL dafür annehmen) unter http:/mm-ho.dyndns.org/oldvisu/ (temp_adjuster.js) noch online.

@luigi: wohl wahr.. Ich ändere das Update-Webif demnächst auf "Überschreibe (mit Backup natürlich) und schweige dabei" aber optimal ist das noch nicht..

Makki

P.S.: war noch unabgesendet von gestern

[luigi4711]

oder vorher die geänderte visu_config.xml aus dem Weg räumen

Command line ist doch noch eher der Weg... denn selbst, wenn keine visu_config.xml existiert (hab sie vorher umbenannt), ist er so schlau zu merken, dass da was nicht stimmt:

Configuration file `/var/www/visu/visu_config.xml'
 ==> Deleted (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : background this process to examine the situation
 The default action is to keep your current version.
*** visu_config.xml (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing cometvisu (--configure):

Hab's über Console wieder gefixt, hier nur als Hinweis für andere.

luigi

[Chris M.]

Was ich noch zur Diskussion stellen wollte: Der Slider: ich glaube man sollte a) noch eine Art Telegrammratenbegrenzung einbauen,

Die sollte schon drinnen sein - bei 250 ms = 4 Telegramme pro Sekunde während des Slidens. Ein Klick ist sofort möglich und wird gleich geschickt.

ebenso eine "Update-Sperre" von 1sek o.ä. nach dem Sliden, weil der sonst zwar technisch korrekt, aber trotzdem optisch nicht so schön "hoppelt". AFAIR hatten wir in der /oldvisu beides soweit in "bastelig" drin.

Kannst Du mir da noch mal den Source schicken?

Im SVN hab ich nun alle Strukturen so weit, dass der Editor jetzt nachziehen kann. D.h. jetzt kann ich mich um die noch offenen, rauhen Ecken des Umstiegs kümmern - und der Slider ist da noch ganz vorne mit dabei...
(Die neuen Transforms sind im SVN nur so weit drinnen, dass der Editor ein Beispiel hat - vollständig oder gar scharf geschaltet sind die noch nicht)

=> Für Gelegenheitsnutzer ist das SVN immer noch nicht bereit. Für Abenteurer dagegen inzwischen wieder schon.

[makki]

CometVisu 0.5.2 ist seit heute Abend auch als Paket im repository - allerdings Pakettechnisch zum letzten weitgehend unverändert.
- bei dem Update per Webif wird es wieder knatschen: entweder ssh-Konsole

apt-get update; apt-get install cometvisu

oder vorher die geänderte visu_config.xml aus dem Weg räumen - anpassen muss man sie eh händisch.

Makki

P.S.: Ich hab den colorchooser vorerst aus der Demovisu rausgenommen, weil irgendwie lief der zuletzt ziemlich wild mit meinen RGB-(gleichen) Rückmeldeadressen - ich wollte hier aber abwarten, bis das mit den Adressen und Transforms umgesetzt ist (weil es direkt damit zu tun hat: hörende GA's dürfen natürlich keine eigenen Schaltaktionen auslösen, auch wenns dieselbe ist)


Was ich noch zur Diskussion stellen wollte: Der Slider: ich glaube man sollte a) noch eine Art Telegrammratenbegrenzung einbauen, ebenso eine "Update-Sperre" von 1sek o.ä. nach dem Sliden, weil der sonst zwar technisch korrekt, aber trotzdem optisch nicht so schön "hoppelt". AFAIR hatten wir in der /oldvisu beides soweit in "bastelig" drin.
Edit: Und das ist wieder so ne Gretchenfrage, weil das ist KNX/DALI-spezifisch, das es nun hier keinen Sinn macht, im 50ms-Takt rauszuknattern, woanders mag das nicht falsch sein!

[Chris M.]

Bei XML bin ich mir bei so etwas immer nicht sicher - wan soll etwas Attribut sein und wann Text-Inhalt.

Nach Principles of XML design: When to use elements versus attributes nehm ich mal die einfache Regel:

data goes in elements, metadata in attributes.

Und finde Julians Vorschlag ganz passend.

[Chris M.]

Wenn das Tag schon address heißt, würde ich statt des src-Attributes den Wert als Content erwarten, also bspw.

<address transform="DPT:9">12/4/250</address>

Bei XML bin ich mir bei so etwas immer nicht sicher - wan soll etwas Attribut sein und wann Text-Inhalt.

Können wir aber gerne ändern.

Abgesehen davon weiß ich nicht so recht wie wir mit der Struktur den Speichervorgang des Editors umsetzen, oder die multiplen Addressen in der Editor-Maske, aber das werden wir auch noch umgesetzt bekommen

Wenn das das einzige Problem ist, dann bin ich ja beruhigt. Denn bekommen wir sich in den Griff.
(Sicherheitshabler der Hinweis: die "attributes:" und "content:" Einträge habe ich nicht wirklich auf die neue Struktur angepasst. Das überlasse ich lieber Dir, damit die mit dem Editor zusammenspielen)

[netzkind]

Hi Chris,

Bitte schaut euch mal die neue Konfig-Syntax an, ob die jetzt so passt und für die Zukunft trägt. Das Info-Widget könnte z.B. so verwendet werden:

    <info styling="BluePurpleRed">
      <label>Slide Info</label>
      <address src="12/4/250" transform="DPT:9" />
      <address src="12/4/251" transform="DPT:9.001" />
    </info>

Wenn das Tag schon address heißt, würde ich statt des src-Attributes den Wert als Content erwarten, also bspw.

    <info styling="BluePurpleRed">
      <label>Slide Info</label>
      <address transform="DPT:9">12/4/250</address>
      <address transform="DPT:9.001">12/4/251</address>
    </info>

Abgesehen davon weiß ich nicht so recht wie wir mit der Struktur den Speichervorgang des Editors umsetzen, oder die multiplen Addressen in der Editor-Maske, aber das werden wir auch noch umgesetzt bekommen

Grüße,
Julian

[Chris M.]

Gerade habe ich die neueste Version (207) in's SVN hochgeladen.

WARNUNG:
Mit dieser Version wird die Konfig-Struktur deutlich geändert! Außerdem ist diese Änderung gerade erst beim Info-Widget umgesetzt, die anderen werden noch folgen. Zudem funktioniert der Editor noch nicht mit der neuen Struktu!

=> Bitte nur updaten, wenn ihr wisst, was ihr tut!

Sobald alles wieder in sich konsistent ist, gebe ich natürlich Bescheid.

Aber:
Bitte schaut euch mal die neue Konfig-Syntax an, ob die jetzt so passt und für die Zukunft trägt. Das Info-Widget könnte z.B. so verwendet werden:

    <info styling="BluePurpleRed">
      <label>Slide Info</label>
      <address src="12/4/250" transform="DPT:9" />
      <address src="12/4/251" transform="DPT:9.001" />
    </info>

D.h. das Label ist in ein eigenes Element gewandert (um so im Zweifel HTML verwenden zu können) und die Adresse ist auch ein Element geworden, um nun auf mehrere hören zu können.
Die Adresse kommt nun auch mit einer Transformation, die bestimmt wie aus den rohen Daten eine JavaScript-native Größe wird. Hier ist in Zukunft noch denkbar Optionen mit anzugeben, die z.B. bei einer Float-Zahl die Darstellung bestimmen (wie Zahl der Nachkommastellen)

[netzkind]

Sorry, mein Fehler.
Zeile 48 ist überflüssig gewesen - habs im SVN korrigiert.

Grüße,
Julian

[Chris M.]

Wollte gerade die SVN-Demo auf Stand bringen, helft mir mal bitte (SVN r200)
[...]Entweder hab ich eine Änderung in der visu_config.xml verpasst oder...

Nö, noch gibt es keine Zwangsänderung an der visu_config.xml

Aber die diagram/structure_plugin.js sieht tatsächlich kaputt aus (von Release 196 auf 197 sind die Variablen w und h weg gekommen, die aber in Zeile 48 gebraucht werden...)

[makki]

Wollte gerade die SVN-Demo auf Stand bringen, helft mir mal bitte (SVN r200)

w is not defined
http://mm-ho.dyndns.org/visu-svn/plugins/diagram/structure_plugin.js
Line 48

Entweder hab ich eine Änderung in der visu_config.xml verpasst oder...

Makki

[Chris M.]

Danke an Julian (netzkind) für zwei weitere gute Designs!
discreet_sand finde ich sehr stimmig. Und discreet_slim macht sich auf einem breiten Monitor (16:9 oder 16:10) sehr gut (meiner, auf dem ich den Screenshot gemacht habe, ist dafür schon fast zu schmal...).

[Chris M.]

CometVisu Release 0.5.2

Sollen wir vorher (=jetzt) ein kurzes Zwischenrelease machen?

So, Release 0.5.2 ist draußen.

So haben wir eine stabile Basis, wenn bei den oben angekündigten Änderungen was schief läuft. Außerdem kann Makki noch mal den Release-Prozess (bzw. Packaging-Prozess) üben. Und nicht zuletzt: Versionsnummern sind preiswert...

0.5.2
=====

- New Feature: Plugins
- New Plugin: colorChooser (based on farbtastic)
- New Feature: user settable status bar (i.e. footer)
- New Feature: iframe widget
- New Plugin: diagrams

[Chris M.]

Oder wir könnten speziell für Widgets bei denen wir davon ausgehen dass der User es in "riesig" nutzen will einen Container schaffen der nicht 48% der Breite nutzt, sondern 98%. @Chris: was meinst du, ich würde hier einfach den Creator duplizieren, neuer Name ("image_fullwidth" bspw), darin eine andere CSS-Klasse (widgetFullwidth bspw.) und das dann in den CSS definieren. Dann muss der User (Admin) aber wissen welche Größe er nutzen will - normal oder xtra-large.

Das ist genau der Teil an der aktuellen Lösung, wo ich hoffte ein begnadeter Web-Designer würde unter die Arme greifen...

Grundsätzlich ist die (absolut unvollständig umgesetzte) Idee ein Mehrspalten-Layout zu haben, wie es sich AFAIK im modernen Weg-Design durchsetzt. Die laufen gerne unter dem Tag 960 (wie z.B. 960 Grid System) weil die auf genau 960 Pixeln Breite eine sehr variable Anzahl an Spalten unterbekommen und es immer perfekt ausgerichtet aussieht.
Da wir hier aber auch mit ziemlich kleinen Ausgabe-Flächen (Smartphone) arbeiten, muss es natürlich die Weiterentwicklung eines 960 Pixel Layout sein - nämlich eines mit variabler Spaltenbreite.
Daraus gibt es zwei Konsequenzen:

1. Die Lösung bei einem übergroßen Inhalt ist die Zahl der verwendeten Spalten zu erhöhen - also aktuell von der halben auf die ganze Bildschirmbreite zu gehen
2. Es fehlt mir noch die grundlegende Idee, wie man die ganzen Spalten automatisch füllen kann - v.a. bei unterschiedlichen Widget Höhen.

Insbesondere bei Punkt 2. ist wichtig im Hinterkopf zu halten, das das aktuelle Text-Layout dafür gedacht ist, mit minimalen Aufwand eine akzeptable(!) Visu hin zu bekommen. Eine gewisse Starrheit und Unflexibilität des Layouts darf da gerne passieren.
Wer höhere Ansprüche hat (und damit auch Zeit oder Geld investiert), wird zur 2D oder 3D Visu greifen, die natürlich alle Layout-Möglichkeiten bietet.