Config-Syntax

[Chris M.]

Das würde die gewählte Implementierung prinzipiell unterstützen

[makki]

Optimalerweise sollte doch das Flavour das(selbe) SVG einfärben(?)

Makki

[Chris M.]

Das sind Erweiterungen die noch kommen sollen...

Für andere Farben wäre Flavour das richtige. Für Orange wäre das bei "Pure" wohl der Flavour "Sodium"...

Type wäre dann für Variationen des gleichen Icons. Z.B. Fenster offen/zu. Hier bin ich mir aber noch nicht sicher ob und wie das Sinn macht.

[mumpf]

Dazu kommt noch eine JavaScript-Datei pro Design mit dem Namen design_setup.js die im jeweiligen Verzeichnis sitzen muss. Dort wird die icon-Struktur befüllt, die die Icon-Namen auf die URLs für die Bildchen mappt.

Hi Chris, ich habe mir das mal angeschaut, die Struktur sieht auch noch einen type und flavour vor, derzeit mit * vorbelegt. Wie ist es denn gedacht, an orangene icons zu kommen? flavour = or? Oder type = or? Und wird es dann bei dem icon-Element noch die Attribute type und flavour geben?
Oder alles in den Namen codieren "audio_mute_or"?
Würde es gerne gleich "richtig" machen...

Danke und Gruß,
Waldemar

[Chris M.]

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

Keine [andere] Meinung heißt meine Meinung!

Icons sind jetzt implementiert

Syntax ist auch sehr simpel und (hoffentlich) universell wie diese Beispiele aus der Demo-Config zeigen:
Icons in Mappings:

      <mapping name="audio_mute">
        <entry value="0"><icon name="audio_mute"/> Aus</entry>
        <entry value="1"><icon name="audio_audio"/></entry>
      </mapping>

Und Icons in Labels:

    <switch mapping="audio_mute">
      <label><icon name="audio_sound" /> Switch Icon</label>
      <address transform="DPT:1.001" type="">12/7/1</address>
    </switch>

Dazu kommt noch eine JavaScript-Datei pro Design mit dem Namen design_setup.js die im jeweiligen Verzeichnis sitzen muss. Dort wird die icon-Struktur befüllt, die die Icon-Namen auf die URLs für die Bildchen mappt.

=> Hier ist bisher nur die Datei für Pure angelegt, die anderen Designs müssen noch ihre Datei befüllen...

[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

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

[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

[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.]

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]

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.]

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.

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

[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

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