CometVisu - (interner) Beta-Test

[michel38]

Hallo Gemeinde,

da ich nun seit Mittwoch auch Besitzer eines WireGate bin , habe ich auch die ersten Test`s gemacht und bin beeindruckt.

Aber...

... gibt es Möglichkeiten ein eigenes Design zu entwerfen? Es gibt da einige Ecken und Kanten, die ich verändern würde, *duck und wech*

[kippi]

... gibt es Möglichkeiten ein eigenes Design zu entwerfen? Es gibt da einige Ecken und Kanten, die ich verändern würde, *duck und wech*

Ich ahne schreckliches ) *G* go Uwe !

[netzkind]

... gibt es Möglichkeiten ein eigenes Design zu entwerfen? Es gibt da einige Ecken und Kanten, die ich verändern würde, *duck und wech*

Na klar gibt es die! Ich sag da aber mal frech: wenn du weißt wie man mit HTML, CSS und Javascript umgeht siehst du ja schon an den Sourcen (/var/www/visu/) was du für ein eigenes Design machen musst.

Falls das nicht der Fall ist mein Vorschlag: verrat uns welche Ecken und Kanten du siehst, wie du sie anders umsetzen würdest - und wir arbeiten dann gemeinsam daran die Visu insgesamt besser zu machen. Dazu gibt es ja auch noch einen eigenen Usability-Thread der aber grade in Hibernation ist

Grüße,
Julian

[Chris M.]

... gibt es Möglichkeiten ein eigenes Design zu entwerfen? Es gibt da einige Ecken und Kanten, die ich verändern würde, *duck und wech*

Selbstverständlich ist das möglich - es ist sogar vorgesehen.

Aktuell gibt's zwei Designs, "pure" und "discreet". Diese leben - so wie es sich gehört - im Unterverzeichnis "designs".
Dein eigenes Design kannst Du dort leicht erstellen, einfach einen eigenen Namen ausdenken und dort ein entsprechendes Verzeichnis erstellen und da drinnen die basic.css und mobile.css erstellen.
Zum einfacheren Testen, hab ich übrigens ein Custom-Widget geschrieben, wo man zur Laufzeit das Design ändern kann...

Solltest Du jedoch eine grundsätzlich andere Struktur wollen, dann müsstest Du eine neue structure_*.js statt der structure_pure.js erstellen. Dieser Wechsel ist jedoch z.Zt. nur angedacht und wird noch nicht unterstützt.

Auch wenn ich es gut finde, wenn weitere Designs entstehen (für die Public Beta hätte ich gerne noch eines mit dunkler Schrift auf hellem Hintergrund), so muss Dir klar sein, dass noch nicht alle internen Strukturen fest stehen und daher das Design leicht kaputt gehen könnte (auch wenn wir probieren dass in Grenzen zu halten)

Apropos interne Strukturen - hier stehen zeitnah ein paar wichtige Änderungen an:

• Das verteilen der neuen Werte auf die Widgets mit den GAs in den CSS-Klassen möchte ich auf ein Subscriber-Modell mit dezentralen Funktionen umstellen (so lassen sich leichter neue Widgets einbauen, der colorChooser würde als erstes davon profitieren)
  => Betrifft nur JS-Entwickler
• Die Addressen in der Konfig-XML möchte ich von Attributen zu Elementen umstellen (so lässt sich auf mehrere GAs gleichzeitig hören, wie bei KNX üblich)
  => betrifft jeden, da die visu_config.xml angepasst werden muss!
• Die Datentypen möchte ich in Transferfunktionen umwandeln. Wahrscheinlich passe ich dazu den Attribut-Namen in der Konfig an, damit es wieder konsistent ist
  => betrifft jeden, da die visu_config.xml angepasst werden muss!
• Jetzt wäre noch ein optimaler Zeitpunkt die Struktur in der Konfig-Datei zu säubern. Gibt es hier Wünsche?

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

[michel38]

Ich sag da aber mal frech: wenn du weißt wie man mit HTML, CSS und Javascript umgeht siehst du ja schon an den Sourcen (/var/www/visu/) was du für ein eigenes Design machen musst.

Das überlasse ich mal Euch. Bit und Byte-schieben ist nicht mein Ding.

verrat uns welche Ecken und Kanten du siehst

Es sind einfach zu wenig Information auf viel Platz. Matthias hat hier gezeigt, wie eine Visu aussehen kann. Ganz mein Geschmack.

Weitere Kanten:

• der Hintergrund ist kleiner als die Grafik
• im oberen Bereich ist ein schwarzer Streifen im Hintergrund, der passt nicht.

[Chris M.]

Matthias hat hier gezeigt, wie eine Visu aussehen kann. Ganz mein Geschmack.

Das ist jetzt ein Vergleich von Äpfeln mit Birnen.

Die CometVisu ist zur Zeit eine reine Text-Visu. Die von Matthias eine 2D-Visu.

Die Erweiterung der CometVisu auf 2D (und sogar 3D!) war bereits angedacht, als die noch nicht mal existierte... Aber wir machen hier einen Schritt nach dem anderen und daher wird es noch bisschen Dauern bis 2D (und 3D) implementiert ist - auch wenn es nicht schwierig ist. (Gerade weil es leicht ist, ist's noch nicht gemacht - es gibt momentan noch dringenderes. Und alles was jetzt schon da ist, wird dabei im Zweifel erst mal unbrauchbar und muss nachgezogen werden...)

[netzkind]

• der Hintergrund ist kleiner als die Grafik
• im oberen Bereich ist ein schwarzer Streifen im Hintergrund, der passt nicht.

1) das ist schwierig. Wir können entweder die Größen so anlegen dass sie sich dynamisch anpassen - dann hat man auf der Seite aber lauter ungleichgroße Boxen und das ganze schaut ziemlich wild aus.
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.
Was mir sowieso nicht an den images und iframes schmeckt: sobald man die gleiche Visu auf Handheld/Smartphone UND 15"-Visu nutzen will schauts auf einem von beiden nach Rübenacker aus. Das aber muss jeder User für sich entscheiden, da ist kein automatisches Mittelchen gegen gewachsen.

2) hab ich bei mir grade gefixt, schafft es bei Gelegenheit dann ins SVN.

Grüße,
Julian

[vento66]

Hallo Gemeinde,

da ich nun seit Mittwoch auch Besitzer eines WireGate bin ,

Na da hat sich der Frankenstammtisch ja mal richtig gelohnt! Und willkommen im "Club"

Sent from my iPhone using Tapatalk

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

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

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

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

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

[netzkind]

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

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)