Aktuelle CV Version

[Chris M.]

Ich dachte das Colspan bezieht sich immer auf den aktuellen Kontext und ist nicht absolut zu lesen?!

Nun, Versuch macht kluch

    <group>
      <layout colspan="6"/>
      <text>
        <layout colspan="6"/>
      </text>
      <text>
        <layout colspan="3"/>
      </text>
      <text>
        <layout colspan="3"/>
      </text>
      <text>
        <layout colspan="2"/>
      </text>
      <text>
        <layout colspan="1"/>
      </text>
      <text>
        <layout colspan="1"/>
      </text>
      <text>
        <layout colspan="2"/>
      </text>
      <text>
        <layout colspan="12"/>
      </text>
    </group>

erzeugt:
Screenshot_20181003_224932.png

Daraus schließen wir:

• Group mit colspan=6 ist wie erwartet die Hälfte (50%) des Bildschirms
• Ein Element mit colspan=6 da drinnen erzeugt 100% - was durch die Group ja 50% des Bildschirms sind
• Zwei mit colspan=3 sind je 50%, also zusammen 100% - was durch die Group ja 50% des Bildschirms sind
• Eines mit colspan=2, 2x colspan=1 und wieder colspan=2 macht 33,3%, 16,6%, 16,6% und 33,3%, also zusammen 100% - was durch die Group ja 50% des Bildschirms sind
• Eines mit colspan=12 machen auch 100%, genau so wie colspan=6 - mehr Spalten als möglich geht halt nicht.

Zusammengefasst: nein, in einer Group wird nicht wieder auf 12 gesetzt, es bleiben nur so viele Spalten wie die Group selber hat.

Da bin ich hochgradig gespannt drauf! :-)

Ist jetzt im drinnen.

[peuter]

Die neue Version der check_config.php ist zwar jetzt drin, aber nach diversen Tests kann ich nun sagen, dass man unter openHAB da eigentlich die Finger von lassen sollte. Leider funktioniert diese komische PHP-in-Java-Geschichte genau an der Stelle nicht gut. Beim Validieren des Schemas werden die Fehler nicht so zurückgegeben, wie das im "normalen"-PHP Interpreter der Fall ist. Die werden gar nicht zurückgegeben sondern direkt ausgegeben. Das könnte man zwar abfangen und aufwendig parsen, um dass dann einigermaßen verständlich auszugeben, aber leider fehlen darin die Zeilenangaben. Selbst mir ist unklar was die Fehlermeldung besagt. Das hilft also niemandem. Die einzige Information die man da rausziehen kann, ist: XML ist valide oder eben nicht.

Zusammengefasst kann ich nur sagen: Wer auch immer die check_config.php braucht um seine Configs zu prüfen, sollte sich eine Webserver mit PHP-Unterstützung einrichten und die CometVisu vom dem ausliefern lassen, die Kommunikation mit dem openhab-cv-backend kann man per proxy weiterleiten.
Zweite Alternative, wäre es einen Freiwilligen zu finden der die check_config.php in Java nachprogrammiert, dann kann die mit ins openhab-cv-backend aufgenommen werden.

[Brn]

• Group mit colspan=6 ist wie erwartet die Hälfte (50%) des Bildschirms
• Ein Element mit colspan=6 da drinnen erzeugt 100% - was durch die Group ja 50% des Bildschirms sind

Genau das habe ich anders verstanden: wenn das Elternelement mit col=6 50% des Bildschirmes einnimmt, sind im Kind Element ja wieder 12 Felder (=100%) frei.
EIn col=6 innerhalb eines col=6 würde für mich 25% des Bildschirms einnehmen, nicht 100% der col=6 Elterngruppe.
In deinem Beispiel sieht man, dass id_0_0 (mit colspan=6) zu 100% führt, während id_0_7 mit col=12 auch zu 100% führt
Zumindest laut Bootstrap entsprechen innerhalb eines Elements col=12 den 100% cund col=6 (50% vom Elternplatz) (https://getbootstrap.com/docs/4.0/layout/grid/#nesting)

...oder stehe ich gerade voll auf dem Schlauch?

Zusammengefasst: nein, in einer Group wird nicht wieder auf 12 gesetzt, es bleiben nur so viele Spalten wie die Group selber hat

Okay. Das soll so. Sorry. Das ist der unterschied zu Bootstrap. Wenn ich meinen Bildschirm bspw. in 4 Teile (col=3) zerlege stehen mir für die Kind-Elemente auch nur noch 3 Unterteilungen zur Verfügung. Da das schnell ein Problem wird, gibt es hier colspan Angaben mit nicht ganzen Zahlen. Wenn man neu in der Thematik ist, hat man das sicher schnell drinnen. Ich darf halt nur nicht den Fehler machen, dass Wissen über die Bootstrap-Welt hier einzubringen, was meine Erste Intention war, weil die Syntax rowspan und colspan gleich ist. Zumindest mich verwirrt es.

[Brn]

Hey, ich habe noch eine Frage zur aktuell in Arbeit befindlichen Version.

Mir ist folgendes aufgefallen: ich habe einen RGB Streifen, den ich auf einer <page> mit 3 Slidern (R,G,B) steuern kann und gleichzeitig habe ich das Colorchooser Plugin dort eingebunden
Wähle ich beim Slider eine Farbe aus, wird der Wert auf dem Colorchooser ebenfalls eingestellt. Soweit gut.
Unmittelbar danach verschiebt sich aber der Wert auf dem Slider und auch der Punkt auf dem Colorchooser wandert wie von Geisterhand einige Farbnuancen weiter.
Andersrum genauso: stelle ich die Farbe auf dem Colorchooser ein, wandert unmittelbar nach dem Einstellen die Slider nach unten und auch der Colorchooser schiebt seinen Markierungspunkt noch ein Stück.

In der Gegenprobe: habe ich nur die Slider für RGB ist alles robust: Wert einstellen und fertig.
Habe ich nur den Colorchooser bleibt das Problem: ich stelle eine Farbe ein, also klicke diese auf dem Farbfeld an, und der Markierungspunkt verschiebt sich immer um ein paar Farbnuancen.

[Chris M.]

Das ist ein Quantisierungsthema: RGB kann jeweils nur 256 verschiedene Werte. Der Colorchooser dagegen wesentlich mehr und v.a. nicht exakt diese Werte sondern auch welche dazwischen.
Wenn Du nun einen Wert anklickst springt der Punkt auf den nächsten einstellbaren/in der Quantisierung darstellbaren Wert.

[Brn]

Wenn Du nun einen Wert anklickst springt der Punkt auf den nächsten einstellbaren/in der Quantisierung darstellbaren Wert.

...und dieser nächste Punkt scheint einen neuen Wert für eine Farbe festzulegen, die in einigen Fällen zu einem anderen Wert führt, als jener, der mit dem Slider eingestellt wurde, wobei der Slider dann einen Wert nach unten rutscht, was wiederum den colorchooser bewegt, ...

So kommt es dann, dass mein bspw. Rotwert von eingetsellten 36 auf 25 runter wandert.
Das funktioniert sogar über GUIs hinweg: wenn ich auf einem Gerät die CometVisu offen habe, aber auf einem anderen Gerät die PaperUI von OpenHab, so kann ich bspw. in der PaperUI einen Wert für eine Farbe einstellen und wie von Geisterhand verschiebt er sich (in aller Regel nach unten), weil der Colorchooser auf einem anderen Gerät den Wert nachkorrigiert.
Schräg

Das heißt was: immer nur ein Bedinelemententyp pro Item? Slider oder Colorchooser?

[Chris M.]

Da muss ich erst mal fragen: welche CometVisu Version?
Hier könnte sich zwischen dem letzten Release (0.10.2) und der aktuellen Entwicklungsversion durchaus was geändert haben...

Eigentlich sollte hier nichts "nachmaulen" wenn ein Wert über den Bus kommt und das Widget den nicht perfekt darstellen kann (dank Displayauflösung quantisiert auch ein Slider...). Aber evtl. passt da was nicht mehr.

[Brn]

Da muss ich erst mal fragen: welche CometVisu Version?

Wie ganz weit vorne geschrieben, hatte ich mich ja bereit erklärt, die aktuelle Beta-Version zu testen und in diesem Zusammenhang baue ich derzeit ein Projekt neu auf. Aktuell nutze ich ein Nightly Build vom 19.09.2018.

Es sind aber auch meine ersten, nennenswerte Schritte mit CV.
Daher kann es sein, dass ich hier Punkte anspreche, die nicht speziell nur für die neue Version zutreffen und bspw. schon seit längerem so gewollt sind, wie etwa das mit dem colspan, was mich wirklich lange verwirrt hat, da ich immer den Bootstrap - Ansatz im Hinterkopf hatte... ;-)

[Chris M.]

Ich habe mal ein Issue dafür angelegt, so das that Thema nicht verloren geht: https://github.com/CometVisu/CometVisu/issues/747

[Chris M.]

Das Issue 747 (https://github.com/CometVisu/CometVisu/issues/747) wurde nun mit dem Pull Request 748 (https://github.com/CometVisu/CometVisu/pull/748) behoben.

=> Brn das mit dem ColorChooser sollte jetzt passen (und bald im Nightly Build enthalten sein)