CometVisu - (interner) Beta-Test

[netzkind]

Aber lässt sich per Editor auch ein anderes Design als 'pure' vorgeben?

Nein.
Auch wenn es auf meiner persönlichen wish list bereits steht.

Das gleiche gilt für Mappings, Stylings und welche Plugins geladen werden.
Die Footer-Leiste auch, aber die ignoriere ich einfach immer.

Grüße,
Julian

[luigi4711]

Kurze Frage:
Es gibt ja das Element Design-Toogle. Aber lässt sich per Editor auch ein anderes Design als 'pure' vorgeben? Über die Shell in der Configdatei ist klar, aber kann ich das auch irgendwie über den Web-Editor ändern, sozusagen die Eigenschaften der 'Hauptseite'!?

Falls nicht, fände ich es gut, wenn es so etwas geben würde, für DAUs. Ich würde dann auch nen Feature Request bei SF aufmachen... wollte nur vorher nachfragen, ob ich da was übersehen habe.

luigi

[JNK]

@Chris M.:

wir können das [multiinfo] auch hier diskutieren. Ich hab das gerade mal mit den groups probiert. Das Schachteln von groups funktioniert soweit, nur hilft es nicht, wenn das widget kleiner ist. Auch ein halb so breites widget wird trotzdem untereinander und nicht nebeneinander in einer group platziert.

Ohne Group geht das ganze, ist ziemlich trivial und lässt sich mit ein oder zwei weiteren Optionen in das bestehende info-widget einbauen ohne das bisherige zu brechen. Man bräuchte dann entweder eine Option um das Label auszublenden und die Breite durch eine zusätzliche Klasse im css zu halbieren oder eben zwei Optionen, wenn man das getrennt voneinander einstellen will.

Gruss,

der Jan

[JNK]

Inzwischen haben wir ja variant.

Sollen wir das noch vor 0.6.0 "reparieren", was bestehende Configs etwas ungültig macht?
Wäre eine nicht komplett triviale Änderung - aber das später den Anwendern zuzumuten wäre wohl noch döfer...

Full Ack. Am besten jetzt. Wo wir gerade dabei sind: Ich habe mit FR 3349648, weil ich es gerade benötige, da habe ich ein "variant"-reicht-nicht Problem:

need some suggestions for further development:

I coded the multiinfo-widget. Current status: working with 1+ addresses of
same format

The displays are in the same order as the group addresses in the config
file and have to be of the same kind because only one "format", "mapping",
"styling"-identifier is used for all addresses (global to widget).

We have only one "variant" per address and there are several possibilities
to use it:

1) as "ordering code", i.e. the address with "1" is first, "2" is second
...
2) as "format code", i.e. the display uses the format specified by
"variant" of adress instead of "format" of the widget
3) as "mapping/styling/format-combi"

1) is worst regarding flexibility, e.g. temperature and humidity can not
be displayed as "21.0 °C 75 % r.h."
3) is best for flexibility but requires extensive parsing of the
"variant"-value and is not very intuitive for users because the
variant-attribute has to be hand-coded while inserting the widget with the
editor
2) seems to be the best compromise but loses the possibility to use
mappings/stylings

Pls comment

[swiss]

Für die CometVisu gibt's schon ein Forum und auch eine Mailingliste - stellt alles SourceForge zur Verfügung, wird aber (noch?) so gut wie nicht genutzt...

Naja das ist für die Entwikler und versierte Anwender die selber weiter etwikeln wollen in Ordnung aber der Endanwender der mit der Programmierung wehnig am Hut hat oder haben will, für den sollte es einen in Deutsch gehaltenes Supportbereich hier im Forum geben. Ob das nun ein separater Bereich wird oder einfach im WG Bereich einfliesst ist da IMHO eigentlich egal.

[Chris M.]

Für die CometVisu gibt's schon ein Forum und auch eine Mailingliste - stellt alles SourceForge zur Verfügung, wird aber (noch?) so gut wie nicht genutzt...

Über ein extra Forum hier hatte ich auch schon nachgedacht, aber ich denke ähnlich wie Stefan, dass man erst mal im offenen WG Forum starten kann, da das WG halt Referenzplattform ist. Die anderen Diskussionen kann man probieren auf das SF-Forum umzuleiten.
Sollte das nicht praktikabel sein, kann man immernoch mit den Admins hier sprechen und ggf. Beiträge verschieben.

[StefanW]

Ich wäre dafür, den Support für die CometVisu im WG-Forum zu leisten.

PS: Warscheinlich wird es ab dem öffentlichen Betatest der CometVisu ohnehin einen eigenes Support-Forum brauchen, damit die ganzen Anfragen nicht im WG bereich oder sonst wo landen.

Kann man darüber nachdenken, aber wir haben im Wiregate Forum zur Zeit gerade mal ein oder zwei neue Threads pro Woche, da kann das CometVisu Thema locker mit rein zumal eine Trennung insofern schwierig ist, da es derzeit die Referenzplattform ist und dann Fragen wie man dies nun mit eibd, 1-Wire-Sensorik. Plugins, scripts, lighthttp, fernzugang per openvpn (wir arbeiten gerade an einem neuen Client), Nutzung eines Hardware Authentikators dafür usw. kombiniert, kommen werden. Es läßt sich also schwer trennen.

In dieser Hinsicht bin ich dafür, dass der Support für die CometVisu im Wiregate Forum bleibt. Was denken die anderen darüber?

LG

Stefan

[swiss]

Ich finde dass weitreichende Änderungen am System am besten noch vor der öffentlichen Beta oder spätestens VOR der Stable Version gemacht werden sollten.

Momentan ist die Zahl der Nutzer die ihre Config ggf. reparieren (anpassen) müssen noch nicht sehr gross. Wenn dann erst mal der Öffentliche Betatest startet, wird warscheinlich die Zahl der Nutzer explodieren.


PS: Warscheinlich wird es ab dem öffentlichen Betatest der CometVisu ohnehin einen eigenes Support-Forum brauchen, damit die ganzen Anfragen nicht im WG bereich oder sonst wo landen.

[Chris M.]

Eine magische Lösung, die nur auf readonly schaut, finde ich auch nicht glücklich, da Dinge gemischt werden, die eigentlich nichts miteinander zu tun haben.

Dann sehen wir das ja gleich.

[...]
Ich glaube hier müssen wir uns entscheiden, für wen das "einfach" sein soll. Man könnte ja auch einfach ein attribute "option" einführen. Beim colorChooser wird das für die Farbe "r", "g", "b" verwendet, hier dann für "info" und "actor".

Ganz allgemein: Ich hab das jetzt funktionierend hinbekommen, aber irgendwie bin ich nicht zufrieden, das scheint mir sehr "unelegant" gelöst.

Inzwischen haben wir ja variant.

Sollen wir das noch vor 0.6.0 "reparieren", was bestehende Configs etwas ungültig macht?
Wäre eine nicht komplett triviale Änderung - aber das später den Anwendern zuzumuten wäre wohl noch döfer...

[swiss]

So...

Ich habe den Bug und den Feature-Request im SF eingetragen.

[Chris M.]

Ich habe um den Abstand zur Linie zu vergrössern weweils vor und nach einer Linie noch ein brake eingefügt. Im Editor wird das richtig dargestellt aber in der normalen Ansicht fehlen alle Zeilenumbrüche die VOR einer Linie eingefügt wurden.

Ah, verstehe.

Ein break ist ein Zeilenumbruch - und kein Abstand (dafür bräuchte man ein nicht existierendes Abstands-Widget...).
Der Editor macht es daher falsch - geauer: bewusst falsch. Denn Du musst ja einem nicht sichtbaren (wie dem Zeilenumbruch) eine sichtbare Form geben, damit der Anwender damit arbeiten kann, wie es z.B. an eine andere Stelle zu verschieben.
Daher hat die Linie auch im Editor nach oben und unten viel Platz und sogar einen Rahmen drum rum...

=> Kein Bug, sondern ein Feature-Request für ein Abstands-Widget

PS: Und noch etwas finde ich nicht ganz geschickt gelöst für den Endanwender... Man sollte beim Installationspaket für das WG unbedingt automatisch die Schreibrechte für die Configdateien einbauen. Ob das direkt oder nur über ein shel-script geht, dass wärend der Installation ausgeführt wird, weiss ich nicht. Aber der Endanwender sollte nicht erst auf die Console müssen um auf der visu_config.xml schreibrechte einzurichten.

Das ist für mich tatsächlich ein Bug.

=> Machst Du den Feature-Request und den Bug-Report auf SF?

[swiss]

Also...

Ich habe um den Abstand zur Linie zu vergrössern weweils vor und nach einer Linie noch ein brake eingefügt. Im Editor wird das richtig dargestellt aber in der normalen Ansicht fehlen alle Zeilenumbrüche die VOR einer Linie eingefügt wurden.


PS: Und noch etwas finde ich nicht ganz geschickt gelöst für den Endanwender... Man sollte beim Installationspaket für das WG unbedingt automatisch die Schreibrechte für die Configdateien einbauen. Ob das direkt oder nur über ein shel-script geht, dass wärend der Installation ausgeführt wird, weiss ich nicht. Aber der Endanwender sollte nicht erst auf die Console müssen um auf der visu_config.xml schreibrechte einzurichten.

[Chris M.]

Nice... schöner wäre die Uhr aber in einem Widget und dann updatebar über die Zeit-GAs auf dem Bus

Jeder ist frei ein Uhr-Widget zu schreiben
Am besten erst mal im (privaten) structure_custom und wenn's dann gut läuft einfach übertragen.

Zeit-GA am Bus sehe ich nicht für notwendig an, da es wesentlich besser ist, den Visu-PC per NTP auf die richtige Zeit zu bringen.

Ich hab noch einen BUG gefungen. Kann dass noch jemand bestätigen?...

Ich habe den aktuellen FF. Wenn ich im Editor ein "break" unter einer Linie einfüge, wird diese korrekt in der Normalansicht dargestellt. Wenn ich den "brake" aber vor einer Linie einfüge, wird die Schaltung ignoriert?

Ein break vor oder hinter einer line macht keinen Sinn (ist aber erlaubt), da die Line sowieso einen break impliziert...

Falls ich da was falsch verstanden habe: mach doch mal einen Screenshot und sag was daran falsch ist.

[swiss]

Ich hab noch einen BUG gefungen. Kann dass noch jemand bestätigen?...

Ich habe den aktuellen FF. Wenn ich im Editor ein "break" unter einer Linie einfüge, wird diese korrekt in der Normalansicht dargestellt. Wenn ich den "brake" aber vor einer Linie einfüge, wird die Schaltung ignoriert?

[swiss]

Jup Ein Uhr widget fänd ich auch nice.

Es könnte ja als Zeitbasis problemlos die Systemzeit genutzt werden. Die ist genau genug und kann über den BUS oder NTP synchronisiert werden.

PS: Könnte man in Widgets auch Themplate nutzen? So könnte mann mit einem Widget (Uhr) Verschiedene Designs nutzen (z.B. Analog / Digital)?