Config-Syntax

[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

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

[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

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

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