CometVisu - (interner) Beta-Test

[netzkind]

Änderungen am Visu-Editor im SVN:
- erweitert sich automatisch auf neue Elemente sofern diese korrekt definiert sind (das Format von visudesign_pure.js und visudesign_custom.js haben sich geändert)
- holt sich GA vom Server, Auswahl als Dropdown
- ergänzt zur GA die DPT
- Validiert die Eingaben

This just in.

Grüße,
Julian

[netzkind]

Neues Design im SVN. Hab es frecherweise schon in der index.html als default eingestellt.

Grüße,
Julian

[vento66]

Hm das WG meldet "Coulnd't find Package Cometvisu"

[makki]

case-sesnsitive: cometvisu..

Makki

[Chris M.]

Neues Design im SVN.

Auch schön , wobei ich meine Vorlage als "edler" empfinde. Aber es war ja eh Ziel möglichst leicht unterschiedliche Designs anzubieten - jetzt muss nur noch die Config-XML erweitert werden, dass dort das Design ausgewählt werden kann. (*)

Als Verbesserungsvorschlag fallen mir bei dem discreet-Design eigentlich nur zwei Kleinigkeiten auf:

• Der Footer ist bei mir schwarz auf Dunkelgrau und damit kaum lesbar
• Ob ein Button gedrückt ist oder nicht, ist an meinem Laptop auch kaum unterscheidbar

Sehr gelungen finde ich dagegen den Gradient hinter den Slidern so wie die grundsätzlcih etwas aufgeräumtere Optik da die Abstände wohl besser gewählt sind (da muss ich morgen mal klauen )

-----
(*) Mein Ziel - aber noch nicht umgesetzt - war bei dem Styling zwei Level anzubieten, ein Design und als Variante dann ein "Flavour". Konkret wäre das Design das was man bisher gesehen hat und was netzkind gerade geändert hat. Das Flavour wäre bei dem klassischen Design unterschiedliche Farben, d.h. das bekannte Orange, oder ein Blau, oder Grün, oder ... - und das Sub-Seiten abhängig.
Die konkrete Umsetzung, v.a. die Auswirkung auf's CSS, habe ich mir aber noch nicht überlegt.

[netzkind]

Auch schön , wobei ich meine Vorlage als "edler" empfinde.

Neben Politik sollte im Forum auch verboten werden über Geschmack zu diskutieren

• Der Footer ist bei mir schwarz auf Dunkelgrau und damit kaum lesbar
• Ob ein Button gedrückt ist oder nicht, ist an meinem Laptop auch kaum unterscheidbar

Der Footer ist ganz bewusst so gewählt - immerhin soll es eine Visu sein die man tendenziell dauerhaft an hat - und kein Werbeträger. Dezent, Wasserzeichenartig. Ist aber ja individuell anpassbar

Die schlechte Unterscheidbarkeit der Buttons hingegen überrascht mich. Ich hab es hier auf vier Endgeräten ausprobiert (Fujitsu-Laptop, MacBook mit nur 6 Bit pro Farbe, Super-AMOLED von Samsung und ein Archos-Tablet - allesamt unkalibriert) um das Problem schwankender Farbdarstellungen je nach Monitoreinstellung garnicht erst aufkommen zu lassen.

Zwei Dinge dazu:
- probier mal style red/green bzw green/red; da ist Unterscheidbarkeit garantiert; wenn weitere Farben benötigt werden kann ich die Grafiken dazu nachliefern
- ich hab eben im SVN noch eine Aufhellung des ungedrückten Buttons eingebaut, damit sollte die Unterscheidbarkeit auch auf Monitoren mit unerwarteter Grau-Darstellung verbessert sein ohne das Grundthema des Designs zu berühren

Sehr gelungen finde ich dagegen den Gradient hinter den Slidern so wie die grundsätzlcih etwas aufgeräumtere Optik da die Abstände wohl besser gewählt sind (da muss ich morgen mal klauen )

Greif zu, es ist genug für alle da

Grüße,
Julian

[Chris M.]

Neben Politik sollte im Forum auch verboten werden über Geschmack zu diskutieren

Da braucht man auch gar nicht drüber diskutieren - schließlich gibt's da kein One-Size-fits-all. Man stelle sich nur eine minimalistische Visu in einem Jodelstiel-Wohnzimmer vor - oder eine prunkvoll verzierte Jugendstil-Visu in einem Glas-Stahl-Beton-Bau

Der Footer ist ganz bewusst so gewählt - immerhin soll es eine Visu sein die man tendenziell dauerhaft an hat - und kein Werbeträger. Dezent, Wasserzeichenartig. Ist aber ja individuell anpassbar

OK, evtl. sollte der noch etwas konfigurierbarer werden.
Grundsätzlich sehe ich den erst mal als Werbe-Fläche für die CometVisu und sollte daher per Default an sein um bei Screenshots zu wirken. Bei der realen Verwendung ist das aber dann natürlich störend und muss weg - oder durch sinnvolle Status-Infos ersetzt werden.

Die schlechte Unterscheidbarkeit der Buttons hingegen überrascht mich. Ich hab es hier auf vier Endgeräten ausprobiert

Auf meiner realen Visu ist's auch deutlich besser als auf meinem Entwicklungs-Laptop.

Zwei Dinge dazu:
- probier mal style red/green bzw green/red; da ist Unterscheidbarkeit garantiert; wenn weitere Farben benötigt werden kann ich die Grafiken dazu nachliefern

Der Effekt ist sehr schön, wenn auch (oder gerade weil) er sehr dezent ist!

Habe gerade sicherheitshalber mal mein Display vom Laptop kalibriert (ok, alte Kalibrierdaten geladen...), da wird's bisschen besser. Aber wahrscheinlich ist das Display einfach zu alt und daher inzwischen zu schlecht.

- ich hab eben im SVN noch eine Aufhellung des ungedrückten Buttons eingebaut, damit sollte die Unterscheidbarkeit auch auf Monitoren mit unerwarteter Grau-Darstellung verbessert sein ohne das Grundthema des Designs zu berühren

Mit dem hab ich bereits die Tests gerade durchgeführt...

[makki]

Nov 6 15:13:07 wiregate116 kernel: [5813696.595003] r[20000]: segfault at 809b5d0 ip 080491c8 sp bf9af180 error 4 in eibread-cgi[8048000+2000]

Also ich finds auf Anhieb nicht. Das das "nicht gut" ist weiss ich schon länger, das der code bullsh** ist wurde mir auch schon gesagt

Evtl. ein C-Mensch anwesend der mir mal kurz und knapp den Kopf waschen mag ?

Die zurecht von mkoegler angemerkten Buffer-overflows machen ja ohne mutwilligkeit keinen Segfault (?), also sitzt da noch ein anderer Hammer im kurzen Spaghetti-Code (Link zum schlechten und schuldigen Source ist ein paar Postings davor); ich programmiere halt trotzdem: wenn ich muss

Makki

[makki]

Jetzt wollt ich grad die Demo-Visu beklicken: edit widget ging bei dimmer usw. kommentarlos nicht, weil die cgi-bin/l fehlte; (ja, ich könnte meine Pakete verwenden aber die Kiste ist von diversen Demo verhunzt )
Nur bei "line", picture und break geht die edit-box auf..
-> Featurewunsch: Fehlermeldung

Firebug:

<b>Warning</b>: parse_ini_file(/etc/wiregate/eibga.conf) [<a href='function.parse-ini-file'>function.parse-ini-file</a>]: failed to open stream: No such file or directory in <b>/var/www/visu/edit/get_addresses.php</b> on line <b>6</b><br />
...

Im Browser alert "parseerror"
-> Featurewunsch: Fehlermeldung - Gruppenadressen importieren o.ä. oder einfach leere Liste. Fehler fände (zumindest ausserhalb des editors) ich auch grundsätzlich in einem "definierten Bereich" (div?) schöner als alert..

Beide Fehler sind nun unwahrscheinlich und sollten natürlich so nicht auftreten (eibga wird mit dem speichern der Sensoren schon geschrieben) aber trotzdem als Anregung..

Editor: Wenn ich eine GA aus der Liste auswähle kommt bei Ok: The value for field 'address' is invalid. Please correct your input.

edit-widget-popup: Wenn man eine geringe Bildschirmhöhe (Netbook 600) hat, kommt man ggfs. nicht mehr an den Ok-Button ran - der Scrollbalken wirkt nur auf Visu im Hintergrund..

editor: Featurewunsch: Dropdown für "Datatype"

Ich tipsel jetzt erstmal ins XML Aber sieht schonmal Klasse aus, wirklich ge** was in dieser kurzen Zeit da geschaffen wurde!

Makki

[netzkind]

Hi makki,

Jetzt wollt ich grad die Demo-Visu beklicken: edit widget ging bei dimmer usw. kommentarlos nicht, weil die cgi-bin/l fehlte; (ja, ich könnte meine Pakete verwenden aber die Kiste ist von diversen Demo verhunzt )
Nur bei "line", picture und break geht die edit-box auf..

Da sollte es programmiertechnisch garkeinen Zusammenhang geben -> versteh ich nicht, muss ich ausprobieren.

Fehler fände (zumindest ausserhalb des editors) ich auch grundsätzlich in einem "definierten Bereich" (div?) schöner als alert..

Dagegen. Also gegen ein DIV. Wieso soll ich das Rad neu erfinden für User-Interaktion wenn es alert, confirm für genau diesen Zweck gibt? Bei allem anderen hol ich mir nur selbstgemachte Probleme mit der Positionierung und der Größe (siehe auch dein Kommentar zum Problem auf dem Netbook) ins Haus.
Das zumindest sehe ich relativ unumstößlich im Editor so.

In der normalen Visu bin ich auch für eine hübsche Fehlerdarstellung, damit man garnicht sieht dass dahinter "nur" ein PC steckt. Die muss dann aber trotzdem auch auf smartphones richtig dargestellt werden (Stichwort: Bildschirmgröße).

-> Featurewunsch: Fehlermeldung

Sicher nicht verkehrt. I'll see what i can do

Editor: Wenn ich eine GA aus der Liste auswähle kommt bei Ok: The value for field 'address' is invalid. Please correct your input.

Gib mal bitte eine oder mehrere GA rüber die er nicht akzeptiert, damit ich schauen kann was dem regulären Ausdruck daran möglicherweise nicht gefällt.

edit-widget-popup: Wenn man eine geringe Bildschirmhöhe (Netbook 600) hat, kommt man ggfs. nicht mehr an den Ok-Button ran - der Scrollbalken wirkt nur auf Visu im Hintergrund..

OK, sollte irgendwie anpassbar sein.

editor: Featurewunsch: Dropdown für "Datatype"

Dazu müssten wir eine Liste aller möglichen DPT anlegen, und am besten mit Namen versehen. Da ich keine Lust habe das aus einem Bild abzutippen: hat jemand das als CSV, XLS oder sonstwie strukturierte Daten rumliegen?

Ich tipsel jetzt erstmal ins XML

Das ist nicht Sinn der Sache. Wenns rumpelt dann gebt mir Reports, dann schaffen wir es noch Klendathu kleinzukriegen

Grüße,
Julian

[NilsS]

(zumindest ausserhalb des editors)

Dagegen. Also gegen ein DIV. Wieso soll ich das Rad neu erfinden für User-Interaktion wenn es alert, confirm für genau diesen Zweck gibt? Bei allem anderen hol ich mir nur selbstgemachte Probleme mit der Positionierung und der Größe (siehe auch dein Kommentar zum Problem auf dem Netbook) ins Haus.
Das zumindest sehe ich relativ unumstößlich im Editor so.

Das Thema hatten wir schon woanders (xxAPI)

zumindest in der Visu hat ne alert Meldung nix zu suchen.

am besten alles per cgi irgendwas an den Server schicken und dort zentral loggen.

[netzkind]

Das Thema hatten wir schon woanders (xxAPI)

zumindest in der Visu hat ne alert Meldung nix zu suchen.

am besten alles per cgi irgendwas an den Server schicken und dort zentral loggen.

Thema Visu hab ich ja bei meine Aussage zugestimmt.

Aber wenn es bei der cgi-Kommunikation Probleme gibt halte ich es für hilflos wenn man dann per cgi was wegloggt. Und wenn die User-Interaktion aus einem dieser Gründe nicht funktioniert, ist wegloggen nur zur späteren Fehlersuche hilfreich - der User muss trotzdem informiert werden dass da grade was nicht so funktioniert hat wie er es erwartet.

Sonst denkt man sich nach dem 28ten Klick auf den Button auch nix Gutes mehr wenn einfach keine sichtbare Reaktion erfolgt.

Grüße,
Julian

[netzkind]

Kurz ein Gedanke in den Raum geworfen:

visudesign_pure erweitern um creator-Methoden für "alert" und "confirm" - dann kann da jeder machen was er will, und wir können erst mal basics festlegen die durchgängig genutzt werden können.

[NilsS]

Na klar ist auch ok, das mit den alert Meldungen ist nur deshalb mist, weil du ja nicht immer an der Visu bist.

Sprich egal cgi irgendwas nicht erreichbar muss da nur solange stehen (oder evtl. nicht mal das sondern "Serververbindung prüfen") solange der Server vielleicht gerade nen reboot macht.

wenn du das mit ner alert machst. dann geht die auch nicht mehr weg.

Es muss ein mechanismus vorhanden sein, der im Fehlerfall Verbindung eine bestimmte Zeit wartet und es danach erneut versucht.

Danach braucht die Meldung keiner mehr auf der Visu.

Bei jeglichen Verbindungsproblemen das Bild mit halbtransparent grau überdecken und Bedienung sperren.

[luigi4711]

Obwohl ich die Threads schon die ganz Zeit mit Begeisterung verfolge, mache ich hier nur erste kleine Schritte.... mein Environment ist alles noch Test, da der Bau noch läuft.

However, zwei Dinge sind mir im Editor aufgefallen:

- Beim einbinden eines Bildes (Typ:image) gibt es ein Feld <text-content>. In der XML Config sind Beispiele drin, in denen dort nichts eingetragen ist und was auch so funktioniert.
Editiere ich allerdings solch einen Eintrag, kommt danach ein 'undefined' vor dem Bild (s.u.). In der Visu ist die Darstellung weiterhin korrekt, bei einem Reload im Editor verschwindet auch das 'undefined' wieder. Es scheint also kein Problem zu sein, hat jedoch bei mir zu Beginn erst mal für etwas Verwirrung gesorgt...

- Zweite Frage: Bei einem Typ:toggle und einem Mapping: onoff kann ich keinen anderen Style auswählen!? Es sollte doch möglich sein einen Toggle Switch zu
erstellen, der Rot/Grün erscheint und Beschriftung an/aus, oder liege ich da falsch?

luigi