Config-Syntax

[Chris M.]

Zitat von makki 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]

Zitat von Chris M. (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.]

Zitat von 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...)

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

=> Commit 759

[Chris M.]

Zitat von 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">
    <layout x="7.5" y="3.7" z="1.0" filter_floor="Underground" filter_room="Room2"/>
    <address transform="DPT:5.001" type="">12/7/53</address>
  </info>
  </filter>
  <info format="%.2f">
    <layout x="3.5" y="7.7" z="1.0" filter_floor="Underground"/>
    <address transform="DPT:5.001" type="">12/7/53</address>
  </info>
  <info format="%.2f">
    <layout x="7.5" y="7.7" z="2.0" filter_floor="Underground"/>
    <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>
  <filter floor="Underground" room="Room2">
    <info format="%.2f">
      <layout x="7.5" y="3.7" z="1.0"/>
      <address transform="DPT:5.001" type="">12/7/53</address>
    </info>
  </filter>
  <filter floor="Underground">
    <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>
  </filter>
</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>
  <floor filter="Underground">
    <room filter="Room2">
      <info format="%.2f">
        <layout x="7.5" y="3.7" z="1.0"/>
        <address transform="DPT:5.001" type="">12/7/53</address>
      </info>
    </room>
  </floor>
  <floor filter="Underground">
    <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>
  </floor>
</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

[Chris M.]

Zitat von 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...

[mumpf]

Zitat von Chris M. 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.]

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.

[makki]

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

Makki

[Chris M.]

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