Config-Syntax

[Chris M.]

In der letzten Zeit haben wir ja an der Syntax rumgeschraubt und die initiale Verfügbarkeit der 3D Seiten bedingt weitere Änderungen, so dass ich in diesem Thread die Diskussion dafür bündeln möchte.

1. "Zugriffs"-Berechtigungen:
Wir haben neben dem "readonly" ja das "writeonly" eingeführt. Damals hatte ich anklingen lassen, dass es evtl. "schöner" wäre das in ein Attribut zu vereinigen, dass dann als Wert "read", "write" oder den Default "readwrite" annehmen kann.
(Jetzt wäre es möglich die Adresse readonly UND writeonly zu setzten, was in sich ein Widerspruch ist...)

2. colspan / rowspan:
(Vgl. auch https://knx-user-forum.de/cometvisu/...n-rowspan.html)
Leider kann ich ohne Beispiel nicht wirklich kommentieren, aber ich befürchte, dass das noch nicht im <layout>-Element steht, wo es IMHO am besten hin gehört.

3. Icons:
Außer dass wir die unterstützen wollen, gibt es keine Implementierung - und somit auch noch keinen Syntax-Vorschlag...

4. 2D und 3D Seiten:
(Der Hauptgrund für mich diesen Thread zu starten)
In der visu_config_2d3d.xml kann man die aktuelle Syntax sehen.

4.1. 2D Seiten:
Mit der verwendeten Beispiels-Syntax sollte das weitestgehend gelöst sein.
Entscheidend ist, dass das Widget ein <layout>-Element bekommt, das z.B. <layout x="0px" y="470px" width="600px" /> sein kann. Mit x und y wird die absolute Position auf der Seite festgelegt, ein width und height die Größe.
Aber wie soll das mit colspan / rowspan zusammen spielen (das IMHO in's <layout> gehört...)?
Wie soll mit einem <group> umgegangen werden?

4.2. 3D Seiten:
Hier stellen sich vielfältige Fragen.
Grundsätzlich sehe ich, dass die Widgets ein <layout> brauchen, bei dem halt noch ein "z" dazu kommt.
Evtl. auch ein "inside"/"outside" Attribut, das festlegt, ob das Widget in das 3D Bild gemalt werden soll, oder außen rum und von dort eine Linie zu diesem Punkt. (Evtl. wäre das aber auch eine Seiten-Option, aber ich könnte mir auch vorstellen, dass man das mischen möchte...)

Das war die einfache Frage da dran - die wesentlich schwierigere ist:
Ein 3D-Grundriss besteht auch mehreren Räumen und Stockwerken. Zwischen diesen kann man interaktiv wechseln - es sind also Quasi Sub-Seiten.
Wie soll man die genau definieren und verbinden?


(Bei all dem würde ich den Editor erst mal außen vor lassen. Wenn wir eine saubere Syntax definiert haben, kann man den dafür anpassen)

[Chris M.]

Das ich diesen Thread oben festgepinnt habe, heißt nicht, dass ich die, äh, rege Diskussion ausbremsen möchte...

Nur wenn klar ist, wer wie über die einzelnen Punkte denkt, können wir weiter kommen!

[JNK]

1. "Zugriffs"-Berechtigungen:
Wir haben neben dem "readonly" ja das "writeonly" eingeführt. Damals hatte ich anklingen lassen, dass es evtl. "schöner" wäre das in ein Attribut zu vereinigen, dass dann als Wert "read", "write" oder den Default "readwrite" annehmen kann.
(Jetzt wäre es möglich die Adresse readonly UND writeonly zu setzten, was in sich ein Widerspruch ist...)

Sehe eich auch so, könnte z.B. "mode" heissen.

2. colspan / rowspan:
(Vgl. auch https://knx-user-forum.de/cometvisu/...n-rowspan.html)
Leider kann ich ohne Beispiel nicht wirklich kommentieren, aber ich befürchte, dass das noch nicht im <layout>-Element steht, wo es IMHO am besten hin gehört.

Das hast Du völlig recht. Ich habe nur im Augenblick leider extrem wenig Zeit, sonst würde ich mir das angucken. Es ist jedenfalls eindeutig ein layout-Feature. Man könnte dann auch gleich extractLayout in .setWidgetLayout einbauen, dann ist da alles beisammen.

3. Icons:
Außer dass wir die unterstützen wollen, gibt es keine Implementierung - und somit auch noch keinen Syntax-Vorschlag...

Ich meine mich zu erinnern, dass es mal einen Implementierungsvorschlag gab, irgendwo hier im Forum. Zur Syntax: Die Frage ist m.E. wie konfigurierbar man das haben will. Soll einfach nur ein Icon fester Größe eingebunden werden, dann geht ein Attribut. Soll z.B. die Größe konfigurierbar sein, dann wäre ein
<icon src="blabla" width="30px" height="30px" [weitere attribute]>Text falls nicht verfügbar</icon> die bessere Wahl.

Zu den restlichen Punkten kann ich nichts sagen oder habe keine Meinung, mir reichen die Möglichkeiten, die die text-basierten Design bieten. Was ich aber nochmnal anmerken möchte:

"multitrigger" mit button1label etc. ist Schrott. Entweder mit einzelnen <button>-Elementen innerhalb des Widgets oder am besten gleich entsorgen, mit colspan="1" oder so kann man das auch mit einem einfachen Trigger lösen. Ggfls. in einer <group> zusammengefasst.

Gruss,

der Jan

[tht]

1. "Zugriffs"-Berechtigungen:
Wir haben neben dem "readonly" ja das "writeonly" eingeführt. Damals hatte ich anklingen lassen, dass es evtl. "schöner" wäre das in ein Attribut zu vereinigen, dass dann als Wert "read", "write" oder den Default "readwrite" annehmen kann.
(Jetzt wäre es möglich die Adresse readonly UND writeonly zu setzten, was in sich ein Widerspruch ist...)

Da ich bisher mehr mit dem Haus zu tun habe, in dem später alles laufen soll und mich bisher daher wenig aktiv damit beschäftigen, verzeiht mir meine möglicherweise unnötige Frage:

Mein grundsätzliches Verständnis wäre folgendes: was ich schreiben kann, kann ich auch lesen/sehen. Genügt es daher nicht für den Default "write" (lesen und schreiben) und für readonly dann "read" zu nehmen?

[micha218]

Mein grundsätzliches Verständnis wäre folgendes: was ich schreiben kann, kann ich auch lesen/sehen. Genügt es daher nicht für den Default "write" (lesen und schreiben) und für readonly dann "read" zu nehmen?

Ohne das Thema "writeonly" bisher im Detail verfolgt zu haben, brauche ich schon die Funktion eine Gruppenadresse nur zu beschreiben und eine weitere nur auszulesen um den aktuellen Status darzustellen. Also "writeonly" ist sinnvoll, wenn der geschriebene Wert gar nicht der Wert ist, der auch als Info angezeigt werden soll.

Gruß

Micha

[Chris M.]

Richtig. Daher hier bitte auf die Syntax und nicht den Sinn konzentrieren.
Über den (Un-)Sinn der verschiedenen Features können wir uns immer gerne in den "normalen" Threads unterhalten.

[makki]

1. "Zugriffs"-Berechtigungen:
Wir haben neben dem "readonly" ja das "writeonly" eingeführt. Damals hatte ich anklingen lassen, dass es evtl. "schöner" wäre das in ein Attribut zu vereinigen, dass dann als Wert "read", "write" oder den Default "readwrite" annehmen kann.
(Jetzt wäre es möglich die Adresse readonly UND writeonly zu setzten, was in sich ein Widerspruch ist...)

Default readwrite wäre IMHO Ok, readonly/writeonly aber eminent wichtig. Auch wenn das die meisten hier sicherlich wissen/verstehen, will ich es nochmal ausführen:
Nach KNX-Lehre hat ein Dimmer z.b.
Schalten (Aktion, writeonly)
Alle schalten (Aktion, writeonly)
Alle im Raum schalten (Aktion, writeonly)
Dimmen absolut (Aktion, writeonly)
Dimmen relativ (Aktion, writeonly)
...

Schaltstatus (Status, passiv, readonly)
Dimmstatus (Status, passiv, readonly)
-> Das sind die einzigen beiden, die auf der Visu angezeigt werden sollten!

Nun können aus praktischen/sonstigen Gründen die Schalt&Status Adresse natürlich gleich sein, aber man kommt damit oft&schnell in den Wald.. Ein häufiger Fehler, ich spreche aus leidvoller Erfahrung..

3. Icons:
Außer dass wir die unterstützen wollen, gibt es keine Implementierung - und somit auch noch keinen Syntax-Vorschlag...

Ohne in aller tiefe darüber nachgedacht zu haben, ich finde das (Icons, 2D/3D/4D) nach 4J Visu (also in gelebt) ohnehin überflüssig, viel wichtiger ist die Visu 4J später ohne Studium in 5 Minuten auch noch pflegen zu können.
Also wenn man in der Richtung Imagetrigger ein paar PNG/GIF/JPG's umschalten kann reicht das für 99% IMHO dicke; Der Rest findet seinen Hafen bei Uwe oder Helmut und ist da gut aufgehoben

4. 2D und 3D Seiten:

Evtl. trennen uns hier 10 halbfertige Visus in 5J in der Meinungsbildung voneinander, ich will (privat!) einfach nur eine funktionale Visu, die 50 Knöpfe für meine 5 Szenen, Solltemperaturen, Rolladen hat, fertig
Mein Fokus liegt auf geht, einfach&hübsch, das erfüllt die CV bereits 99%, an der Perfektion dieses kann man arbeiten, an der Ausweitung zu einem Malprogramm á la XXX habe ich ehrlichgesagt weniger Interesse

Makki

[greentux]

Da haben der Makki und ich ja mal den gleichen Geschmack
KISS Visu brauch ich auch nur. Aber vl. gehts ja in der Tat bei der CV so umzusetzen, das man beides hat...

[Chris M.]

KISS Visu brauch ich auch nur. Aber vl. gehts ja in der Tat bei der CV so umzusetzen, das man beides hat...

Ja das geht. Text-Mode neben 2D und 3D (sogar beliebig gemischt geht auch)

Deswegen ist es wichtig, dass wir eine saubere Syntax definieren, mit der das auch intuitiv geht.

[makki]

Hmm, ich nehme mir dann erstmal vor, das der Editor (das IMHO wichtigste an einer Freak&Sehenscheidentzündungs-freien Visu) wieder läuft
Kein Vorwurf, war klar, das es da Anpassungsbedarf gibt..

@greentux: nun, das ist mein Ziel, übrigens ganz privat. Ich freue mich über 2D/3D trotzdem, weil ich um die Lemming-Wirkung weiss, braucht die Welt zwar (theoretisch!) nicht aber praktisch macht es eine Menge aus. Nur psychologisch natürlich (IMHO), sieht subba aus, man glaubt an was, am Ende des Tages erkennt man dann aber, das man die 8h im Monat lieber für was anderes verwendet, als die Visu zu pflegen.. Wenn man sein Selbstwertgefühl nicht daraus ableitet, dem Nachbarn das eigene Haus in 3D auf dem Touchpanel im Flur zu präsentieren.. egal
(oder man bezahlt jemanden dafür, diese Fraktion - AG&AN - kann ich auch absolut verstehen! da greift dann mein sportlicher Ehrgeiz, anderen Lösungen Anteile abzujagen - da sprechen wir aber über milli..)

Auch Makefile finde ich gut, auch wenn Automake und ich in diesem Leben sicher keine dicken Freunde mehr werden weil doch a bisserl krank ist, es ist gut & das geringste übel - und am Ende des Tages wäre es für alle bequemer aus einer configure.ac automatisch das Packerl für verschiedene Plattformen mit allen depends automatisch zu bauen.. Der Weg ist lang und steinig, aber die Richtung stimmt..

Soweit, Makki

[Chris M.]

Auch Makefile finde ich gut, auch wenn Automake und ich in diesem Leben sicher keine dicken Freunde mehr werden weil doch a bisserl krank ist, es ist gut & das geringste übel - und am Ende des Tages wäre es für alle bequemer aus einer configure.ac automatisch das Packerl für verschiedene Plattformen mit allen depends automatisch zu bauen..

So lang sich keiner freiwillig meldet, sich um das Build-System der CometVisu kümmern zu wollen, wird's bei handgeschriebener Makefile und ggf. ein paar Bash-Skripten bleiben...
(Ich kann ja schon keine Makefiles - wie soll ich dann auf Automake gehen? )

[makki]

(Ich kann ja schon keine Makefiles - wie soll ich dann auf Automake gehen? )

Ich auch nicht, aber man lernt halt sich damit zurechtzufinden, Makefile: sehr obskur: Auto* sieht erstmal noch schlimmer aus, ist auch obskur aber eine configure.ac zu machen (aus der der Rest entsteht) ist nicht IMHO so weniger krank wie m4 ansich..
Brauchen wir hier aber eigentlich garnicht, da wird ja nichts gebaut, kein libtool (das wirds dann erst richtig "magic"!!);
mal angenommen das Backend schafft es mal in den eibd(wer kann C und erbarmt sich?)
Sonst schleppen wir das mit und dann brauchts das sogar, damit wir die richtige pthsem...so einsammeln und so
Kann ich aber auch gerne drauf verzichten

Makki

[Chris M.]

1. "Zugriffs"-Berechtigungen:
Wir haben neben dem "readonly" ja das "writeonly" eingeführt. Damals hatte ich anklingen lassen, dass es evtl. "schöner" wäre das in ein Attribut zu vereinigen, dass dann als Wert "read", "write" oder den Default "readwrite" annehmen kann.
(Jetzt wäre es möglich die Adresse readonly UND writeonly zu setzten, was in sich ein Widerspruch ist...)

Sehe eich auch so, könnte z.B. "mode" heissen.

=> Commit 759

[Chris M.]

4.2. 3D Seiten:
Ein 3D-Grundriss besteht auch mehreren Räumen und Stockwerken. Zwischen diesen kann man interaktiv wechseln - es sind also Quasi Sub-Seiten.
Wie soll man die genau definieren und verbinden?

Gerade grüble ich über dieser Frage. Mir fallen 3 Lösungsmöglichkeiten für die Syntax ein:

1. Im Layout:

<page name="3D Demo" type="3d" backdrop="floorplan_demo.xml" azimut="12/7/53" elevation="12/7/54" floor="12/7/51">
  <info format="%.2f">
    <layout x="3.5" y="3.7" z="1.0"/>
    <address transform="DPT:5.001" type="">12/7/53</address>
  </info>
  <info format="%.2f">
    <[B]layout[/B] x="7.5" y="3.7" z="1.0" [B]filter_floor="Underground" filter_room="Room2"[/B]/>
    <address transform="DPT:5.001" type="">12/7/53</address>
  </info>
  </filter>
  <info format="%.2f">
    <[B]layout[/B] x="3.5" y="7.7" z="1.0" [B]filter_floor="Underground"[/B]/>
    <address transform="DPT:5.001" type="">12/7/53</address>
  </info>
  <info format="%.2f">
    <[B]layout[/B] x="7.5" y="7.7" z="2.0" [B]filter_floor="Underground"[/B]/>
    <address transform="DPT:5.001" type="">12/7/53</address>
  </info>
</page>

2. Per Filter-Elemente:

<page name="3D Demo" type="3d" backdrop="floorplan_demo.xml" azimut="12/7/53" elevation="12/7/54" floor="12/7/51">
  <info format="%.2f">
    <layout x="3.5" y="3.7" z="1.0"/>
    <address transform="DPT:5.001" type="">12/7/53</address>
  </info>
  [B]<filter floor="Underground" room="Room2">[/B]
    <info format="%.2f">
      <layout x="7.5" y="3.7" z="1.0"/>
      <address transform="DPT:5.001" type="">12/7/53</address>
    </info>
  [B]</filter>
  <filter floor="Underground">[/B]
    <info format="%.2f">
      <layout x="3.5" y="7.7" z="1.0"/>
      <address transform="DPT:5.001" type="">12/7/53</address>
    </info>
    <info format="%.2f">
      <layout x="7.5" y="7.7" z="2.0"/>
      <address transform="DPT:5.001" type="">12/7/53</address>
    </info>
  [B]</filter>[/B]
</page>

3. Getrennte Filter-Elemente für floor und room:

<page name="3D Demo" type="3d" backdrop="floorplan_demo.xml" azimut="12/7/53" elevation="12/7/54" floor="12/7/51">
  <info format="%.2f">
    <layout x="3.5" y="3.7" z="1.0"/>
    <address transform="DPT:5.001" type="">12/7/53</address>
  </info>
  [B]<floor filter="Underground">
    <room filter="Room2">[/B]
      <info format="%.2f">
        <layout x="7.5" y="3.7" z="1.0"/>
        <address transform="DPT:5.001" type="">12/7/53</address>
      </info>
    [B]</room>
  </floor>
  <floor filter="Underground">[/B]
    <info format="%.2f">
      <layout x="3.5" y="7.7" z="1.0"/>
      <address transform="DPT:5.001" type="">12/7/53</address>
    </info>
    <info format="%.2f">
      <layout x="7.5" y="7.7" z="2.0"/>
      <address transform="DPT:5.001" type="">12/7/53</address>
    </info>
  [B]</floor>[/B]
</page>

Gibt es hier Präferenzen? Vor- und Nachteile?

Hinweis: Ziel sollte primär eine hohe Ausdruckskraft und Zukunftssicherheit sein. Eine einfache Implementierung ist nur nachrangig wichtig...

[JNK]

Ich hab keine echte Präferenz, aber 2) scheint mir am meisten für Übersichtlichkeit zu sorgen, weil

1) Der Filter ist aussenrum
2) Alle Filter stehen zusammen

Und man gewinnt nicht mehr Flexibilität als in 3), weil man ja einfach weitere Attribute hinzufügen kann.

Gruss,

der Jan