CometVisu - (interner) Beta-Test

[JNK]

Hallo,

ich habe ein Feature für mich implementiert, wenn gewünscht kann ich das gerne einchecken. Beschreibung:

Gegeben: ein "+" und ein "-" Button als 'multitrigger'. im pure-design sieht das ziemlich unschön aus, da die Button-Beschriftung text-align:left hat. Ich habe jetzt implementiert, das man bei 'trigger', 'multitrigger' und 'switch' als 'attribute' ein Alignment angeben kann. Sieht dann wie folgt aus:

<multitrigger align="center" button1label="+" button1value="0" button2label="-" button2value="1">
        <label>Temperatur Soll</label>
        <address transform="DPT:1">1/1/3</address>
      </multitrigger>

Entsprechend das gleiche gilt dann für 'switch' und 'trigger'. Default ist 'left' wenn nichts angebeben ist, also so wie es jetzt im Augenblick auch ist.

Wollt ihr das?

Gruss,

der Jan

[Chris M.]

Wollt ihr das?

Finde ich gut!

[makki]

@JNK: das sollte eigentlich gefixed sein (bis auf die Farbe, s.u.), bitte Info ob ack/nack..
Align: Wie schrieb Chris kürzlich zu mir: "Wo ist der svn-commit?"


Andere Sachen:
- ich wollte mich mal den Farben der Linien in den diagrammen annehmen (habs evtl. auch selber halb versaubeteult): in pure sollten die halt orange sein, in discreet jedenfalls irgend was anderes als das Grid. Mittelgrau.. Einwände/Vorschläge?
- alte Frage aufgewärmt: gesetzt den Fall ich bekomme es hin (50:50):
Das scrollen geht ja auf Touch garnicht und im normalen Browser nur recht leidig(man muss wissen wie..nervt..), ich wäre als pseudo-Lösung immernoch für eine Option, das nicht auf den Schirm passende Widgets einfach auf jquery-Tabs/Pages (siehe /oldvisu) automatisch verteilt werden. ->Einwände?
(ich will immernoch eine "Auto-Visu": break und line halte ich für Deko )

Makki

[JNK]

@JNK: das sollte eigentlich gefixed sein (bis auf die Farbe, s.u.), bitte Info ob ack/nack..

Äh, was? das mit der Popup-Vorschau? Ist es. Habe ich auch als Fixed markiert.

Align: Wie schrieb Chris kürzlich zu mir: "Wo ist der svn-commit?"

Ok. Werde ich dann einchecken.

Andere Sachen:
- ich wollte mich mal den Farben der Linien in den diagrammen annehmen (habs evtl. auch selber halb versaubeteult): in pure sollten die halt orange sein, in discreet jedenfalls irgend was anderes als das Grid. Mittelgrau.. Einwände/Vorschläge?

In 'pure' sollten die meiner Meinung nach die Farbe haben, die im Flavour vorgegeben ist.

Gruss,

der Jan

[manu241]

Hallo Jan,

wie erhöhst du denn den Sollwert ? Hast du hinter den Buttons eine Logikfunktion ?

Wenn ja, wie sieht diese aus ? Wie ist diese Verknüpft etc ?

Gruß Manuel

[JNK]

Hallo Jan,

wie erhöhst du denn den Sollwert ? Hast du hinter den Buttons eine Logikfunktion ?

Wenn ja, wie sieht diese aus ? Wie ist diese Verknüpft etc ?

Gruß Manuel

Äh. Äh. So weit bin ich noch nicht. Was ich mir vorstelle ist, dass eine Logik auf die GA hört, den Sollwert aus dem Heizungsaktor ausliest und dann einen neuen Sollwert +/- 0,5 °C sendet. Ob das geht weiss ich mangels Heizungsaktor nicht, die MDT sollen aber mit Soll- und Ist-Wert die Regelung selbst machen. Ist-Wert kommt vom Wiregate, Sollwert dann eben von der Logik über die Visu. Liefertermin ist 10. Juni, dann kann ich Dir mehr sagen.

[manu241]

Hallo Jan,

achso du bist nur bei der Visu. Ich dachte du nutzt diese schon Live.
Mal sehen was Makki dazu sagt was man da machen kann.

Gruß Manuel

[Chris M.]

- ich wollte mich mal den Farben der Linien in den diagrammen annehmen (habs evtl. auch selber halb versaubeteult): in pure sollten die halt orange sein, in discreet jedenfalls irgend was anderes als das Grid. Mittelgrau.. Einwände/Vorschläge?

Das letzte mal, wo ich mir das angesehen hatte, hatte sich das Plugin die Farbe aus der Seite selbst geholt - was eigentlich genau der richtige Weg ist. Denn das Plugin kann nie wissen, wie die Seite aussehen soll - dass weiß nur das CSS.

- alte Frage aufgewärmt: gesetzt den Fall ich bekomme es hin (50:50):
Das scrollen geht ja auf Touch garnicht und im normalen Browser nur recht leidig(man muss wissen wie..nervt..), ich wäre als pseudo-Lösung immernoch für eine Option, das nicht auf den Schirm passende Widgets einfach auf jquery-Tabs/Pages (siehe /oldvisu) automatisch verteilt werden. ->Einwände?

Ohne Beispiel kann ich mir da gerade wenig vorstellen.

Meine Idee bei der Text-Visu war, das so zu haben, wie man es immer bei der Smartphone-Werbung sieht:
Hoch/Runter-Scrollen geht per Irgendwo-touchen-und-hoch/runter-ziehen.
Seiten-Wechsel geht per Verschieben des Bildschirminhaltes nach links/rechts.

Mangels Smartphone kann ich das nicht testen bzw. die Berichte, dass das nicht mag, nicht nachvollziehen. Auf dem PC macht's das (fast). Was da noch fehlt, ist die Scrollbar dadurch zu "ersetzen", dass man überall im Bildschirm "anfassen" kann. Das sollte sich aber noch leicht einbauen lassen (keine Ahnung welche Querwirkungen das mit Smartphones hat, die diese Funktionalität ja schon im Browser selbst haben)

Äh. Äh. So weit bin ich noch nicht. Was ich mir vorstelle ist, dass eine Logik auf die GA hört, den Sollwert aus dem Heizungsaktor ausliest und dann einen neuen Sollwert +/- 0,5 °C sendet.

Wenn man das PI-Regler-Plugin passend erweitert, ist das leicht möglich.

Vermutlich sollte man dem aber ein eigenes Widget spendieren, dass gleichzeitig die Soll-Temperatur mit anzeigt.

[makki]

Das letzte mal, wo ich mir das angesehen hatte, hatte sich das Plugin die Farbe aus der Seite selbst geholt - was eigentlich genau der richtige Weg ist. Denn das Plugin kann nie wissen, wie die Seite aussehen soll - dass weiß nur das CSS.

Das ist jetzt so eine Sache mit CSS und flavors die ich ehrlichgesagt noch nicht ganz blicke Ich weiss zwar wie ich jetzt *irgendwie* die Farben ändere aber ich würds gern verstehen, wie es richtig&gedacht ist.
Irgendwas ist da zumindest bei mir verhunzt, wo genau sollte (um beim Beispiel diagram_popup zu bleiben) die Farbe der Linie stehen ?

Ohne Beispiel kann ich mir da gerade wenig vorstellen.

Hier
Ich würde es so ähnlich (!) machen;
Scrollen finde ich ehrlichgesagt blöd, es geht schon aufm Desktop nur sehr leidig.. Scrollbalken wären hässlich..
Die Navigationsbuttons würde ich allerdings nicht mehr in die Ecke packen, das ist in der Praxis IMHO schlecht bedienbar.
So oder so (ohne Slideshow natürlich)
Man beachte, das man mit den kleinen Bommeln unten auch Seiten anspringen kann.. (die dürfen ja auch etwas grösser sein)

Hoch/Runter-Scrollen geht per Irgendwo-touchen-und-hoch/runter-ziehen.
Seiten-Wechsel geht per Verschieben des Bildschirminhaltes nach links/rechts.

Genau.. links rechts sliden kann man sicher abfangen und damit die Tabs springen lassen.
Ich will langsam endlich meine HS-Visu abschaffen
Auf dem mobile ist das aber noch leicht holprig, die Navigation mit dem page-namen links oben z.B. da bricht man sich jedesmal nen Finger, in einer perfekten Welt lässt sich die Visu mitm dicken Daumen bedienen..
Zum testen geht das Andriod-SDK mit dem emulator eigentlich ganz gut (bzw. ist es eh bequemer aber das "feeling" fehlt natürlich wie z.B. das die obere linke Ecke einfach nicht direkt erreichbar ist)

Makki

[Chris M.]

Das ist jetzt so eine Sache mit CSS und flavors die ich ehrlichgesagt noch nicht ganz blicke Ich weiss zwar wie ich jetzt *irgendwie* die Farben ändere aber ich würds gern verstehen, wie es richtig&gedacht ist.

Flavour ist eigentlich ganz einfach:
Das Design der CometVisu lässt sich auf drei verschiedenen Ebenen anpassen:

1. Das prinzipielle Aussehen, Seitenaufbau, Navigation, ... Hier gibt es zur Zeit nur eine Implementierung (nämlich die in templateengine.js), d.h. es weiß kaum einer, dass man hier zumindest theoretisch wählen könnte
2. Das Design. Hier wird einfach per entsprechender CSS definiert, wie die Widgets konkret aussehen, d.h. Farben und Formen. Hier gibt's die bekannten Varianten wie "pure" und "discreet"
3. Der Flavour. Jedes Design(!) kann Flavours definieren, die quasi die "Geschmacksrichtung" der entsprechenden Seite definieren. Z.Zt. sind die nur im Design "pure" definiert und bestimmen dort die Akzent-Farbe.
   (In naher Zukunft werde ich noch Gruppen einbauen, d.h. einen optischen Rahmen um Widgets, um auf einer Seite für mehr Struktur sorgen zu können. Denen werde ich auch Flavours geben, die dort den Rahmen oder den Hintergrund bestimmen können)

D.h. das Diagramm sollte sich in der Farbe des aktuellen Flavours malen.

Irgendwas ist da zumindest bei mir verhunzt, wo genau sollte (um beim Beispiel diagram_popup zu bleiben) die Farbe der Linie stehen ?

Im Zweifel ist immer die config=demo entscheidend. Wenn die mag (und die hat Flavour-Beispiele drinnen), dann ist die Installation i.O.

Zum testen geht das Andriod-SDK mit dem emulator eigentlich ganz gut (bzw. ist es eh bequemer aber das "feeling" fehlt natürlich wie z.B. das die obere linke Ecke einfach nicht direkt erreichbar ist)

An dem stören mich drei Dinge, hoffentlich liegen möglichst viele davon an meiner Unfähigkeit:

1. Sau lahm (trotz Core i7 und Hauptspeicher der für zwei 32 Bit Systeme mehr als reichen würde)
2. Ich kann den Browser-Cache nicht ausschalten (nur per Hand löschen, das macht aber wegen 1. keinen Spaß)
3. Ich weiß nicht wie ich an die Browser internen Debug-Infos a la FireBug komme.

[makki]

Flavour ist eigentlich ganz einfach:
Das Design der CometVisu lässt sich auf drei verschiedenen Ebenen anpassen:

Sorry, ich stehe da immernoch grob auf dem Schlauch Wo steht das flavour lithium=Farbe xy? Mag ne dumme Frage sein, aber ich kapiers nicht ganz..


1) ist klar (heisst nicht das ich wüsste es zu erweitern aber das wäre der Ansatz um aus dem jetzigen jQ-Tabs/Slides zu machen..)

[*]Das Design. Hier wird einfach per entsprechender CSS definiert, wie die Widgets konkret aussehen, d.h. Farben und Formen. Hier gibt's die bekannten Varianten wie "pure" und "discreet"

Das ist schon hinbekommen (in der demo-visu gibts pure_mobile)

[*]Der Flavour. Jedes Design(!) kann Flavours definieren, die quasi die "Geschmacksrichtung" der entsprechenden Seite definieren. Z.Zt. sind die nur im Design "pure" definiert und bestimmen dort die Akzent-Farbe.

Gut, da hats jetzt gerade "klick" gemacht.. Ok, das Diagramm hat in den Kurven immer die Farbe des initialen Designs (ich schätze mal das darf man fehlendes Feature der discreet-Design nennen, ist aber jetzt nicht so wichtig, ich wills verstehen warum..)

An dem stören mich drei Dinge, hoffentlich liegen möglichst viele davon an meiner Unfähigkeit:
[LIST=1][*]Sau lahm (trotz Core i7 und Hauptspeicher der für zwei 32 Bit Systeme mehr als reichen würde)

Naja, es ist Java Aber ich würde sagen: zum testen ok, läuft auf meinem dagegen mickrickigen Core2 Duo P8700 flüssig. Ich bin aber 32Bit-Fan, vielleicht liegts daran (und Java..)
Sonst haben wir ja vermutlich dasselbe OS drauf, Windows 10.04,10.10,11.04 ging..

[*]Ich kann den Browser-Cache nicht ausschalten (nur per Hand löschen,

lästig, ja, aber zum testen und entwickeln kann man ja den Desktop-Browser verwenden, zum finetuning dann den Emu; finde ich ehrlichgesagt immernoch komfortabler als das Endgerät selbst..
Wenigstens hat man da den adb-Debugger-Logger.. Aber bis Android und ich echte Freunde werden, wird auch noch ne Weile vergehen Beim derzeitigen Marktanteil ohne sichtbare bessere Alternativen (Maemo/MeeGo wäre meins aber naja, das ist halt eher tot) hab ich mich halt vorerst einfach nur damit abgefunden das es so ist wie es ist. Besser als Apple

Als Ziel sehe ich hier übrigens primär/ausschliesslich den Onboard-Webkit (Chrome/Safari), den sich die beiden derzeit verbreiteten Smartphone-Plattformen ja quasi teilen, ob das mit einem Fancy-XY-Opera/Mobile-FF oder sonstwas läuft halte ich für sekundär (und ich habe selber ein Smartphone, auf dem FF4 läuft aber kein Webkit.. aber das ist nunmal nicht kriegsentscheidend..)

-> Aber das ist IMHO die Killerapplikation, das muss aufm mobile genauso lüppen wie ein sch*** Command(con)fusion und das tut es ja schon fast (um real, endlich, nochmal, das dämliche Gerücht zu wiederlegen das sowas mitm Browser ohne "App" nicht auch in realtime ginge.. tuts nämlich..)

Makki

[Chris M.]

Sorry, ich stehe da immernoch grob auf dem Schlauch Wo steht das flavour lithium=Farbe xy? Mag ne dumme Frage sein, aber ich kapiers nicht ganz..

In der normale Konfig-Datei steht beim <page> Element, welchen Flavour es haben soll (optional, Fallback auf Standard).
Das Aussehen des Flavours ist in der entsprechenden CSS definiert, z.B. in /designs/pure/basic.css so ab Zeile 329.

Die Darstellung funktioniert übrigens darüber, dass die Styles "überladen" lassen, d.h. demm Class-Attribut einer Seite einfach zuätzlich noch eine Flavour-Klasse hinzugefügt wird. (Am besten einfach mal das HTML im FireBug ansehen, dann wird der Satz klar )

Wenn nun ein Element die Akzent-Farbe eines Flavours haben möchte, dann sollte es vermutlich auf die background-color des <hr> schauen.

[JNK]

@ ChrisM:

Eigenes Widget fänd ich gut. Vielleicht versuch ich mich daam Wochenende mal dran. Praktisch wärs auf jeden Fall, im Prinzipo eine Kombi aus Multitrigger und info.

@manu:

Das Plugin ist fertig, das funktioniert so, aber ich wollte das noch auf mehrere Kanäle aufbohren, bevor ich das veröffentliche.

Gruss,

der Jan

[Chris M.]

Eigenes Widget fänd ich gut. Vielleicht versuch ich mich daam Wochenende mal dran. Praktisch wärs auf jeden Fall, im Prinzipo eine Kombi aus Multitrigger und info.

Dafür gibt es 2-3 Wege:

1. Offizielles Widget (d.h. in structure_pure.js), das bekommt jeder immer
2. Plugin (d.h. Unterverzeichnis unter /plugins/), das kann man bei Bedarf dazu laden
3. Eine private Erweiterung, d.h. in structure_custom.js - die darf jeder überschreiben und sollte vom Paket-Management nicht angefasst werden.

Bei jedem neuen Widget sollte man sich überlegen, wo es am besten rein gehört.
In 2. kommen "große" und "fette" Dinge, d.h. Widgets die die Ladezeit verzögern können und die viele nicht zwingend brauchen. Das hier beschriebene Widget ist dagegen klein, d.h. in 2. passt es nicht so ganz.
Der Unterschied zwischen 1. und 3. ist eigentlich nur, ob das für die Allgemeinheit wichtig ist (-> 1.) oder nicht (-> 3.)
So ein Temperatur-Wähler halte ich für die Allgemeinheit für sinnvoll => 1. wäre meine Wahl

Das Plugin ist fertig, das funktioniert so, aber ich wollte das noch auf mehrere Kanäle aufbohren, bevor ich das veröffentliche.

Ich hatte bei meinen PI-Regler-Plugins mir am Anfang auch öfters gewünscht, die in einem großen Plugin zu sammeln.
Da ich aber bei manchen eine zeitbasierte Umschaltung eingebaut habe, etc. bin ich inzwischen eigentlich froh, dass ich für jeden Heizkreis ein eigenes Plugin habe.

[manu241]

Hallo,

ich habe aber nicht nur das Wiregate sondern auch Biq´s die gefüttert werden müssen mit dem Sollwert. Daher muss dafür bestimmt ein extra Plugin geschrieben werden.

Gruß Manuel