Der Typenkatalog

Beispielmodul: hellotypes.

Die Elementtypen gliedern sich in zwei Familien.

Typen, die auf der Oberfläche zwangsläufig nur lesbar sind

ElementLight (Statusanzeige), ElementImg (Bild), ElementVideo (Videostream), ElementPrg (Fortschrittsbalken oder Spinner) — keiner von ihnen ergibt als direkt editierbares Element von einem Client aus Sinn.

Bild: die Webroot-Konvention

Ein Modul schreibt seine Datei nach getWebroot() + "/" + getModuleName() + "/..." und gibt dem Element eine URL, die relativ zu diesem Ort ist:

QDir dir;
dir.mkdir(getWebroot() + "/" + getModuleName());
atomicSaveJpeg(img, getWebroot() + "/" + getModuleName() + "/photo.jpeg");

OST::ImgData data;
data.mUrlJpeg = getModuleName() + "/photo.jpeg";
getEltImg("display", "photo")->setValue(data, true);
getWebroot() ist im Konstruktor noch nicht definiert

Der Controller ruft setWebroot() auf einem Modul erst nach der Rückkehr aus dessen Konstruktor auf. Jeder Code, der eine vom Webroot abhängige Datei schreibt, muss daher auf die nächste Iteration der Ereignisschleife verschoben werden:

QTimer::singleShot(0, this, [this]() {
    // getWebroot() est maintenant garanti défini.
});

ElementVideo folgt genau derselben URL-Konvention (OST::VideoData::url), für einen anderswo bereits bestehenden Stream.

Fortschrittsbalken und Spinner: beide durch einen Wert gesteuert

ElementPrg hat zwei Darstellungen (prgtype: "bar" oder "spinner"), aber beide werden durch einen Wert von 0-100 bestimmt — ein Spinner ist keine unbestimmte Aktivitätsanzeige, sondern ein Ring, dessen Füllung setPrgValue() folgt, genau wie der Balken:

getEltPrg("display", "progress")->setPrgValue(42.0, true);
getEltPrg("display", "spinner")->setPrgValue(42.0, true);   // oui, le spinner aussi
getEltPrg("display", "spinner")->setDynLabel("En cours...", true);

Normalerweise editierbare Typen

ElementBool, ElementString, ElementInt, ElementFloat, ElementDate, ElementTime, ElementDateTime — alle können auf Ebene ihrer Property (permission:0) auf nur lesbar gesperrt werden, unabhängig von jeder Einstellung auf Elementebene (directedit, autoupdate): die Permission-Prüfung wird als Erstes geprüft, vor allem anderen.

Numerische Beschränkungen und Tooltip

Für int/float gibt es vier zusätzliche optionale JSON-Schlüssel:

"gain": { "type": "float", "directedit": true, "min": 0, "max": 100, "step": 1, "format": "%.0f", "hint": "Gain capteur" }
  • min/max: zulässige Grenzwerte.
  • step: Schrittweite der Steuerung auf Client-Seite.
  • format: Anzeigeformat (printf-Stil).
  • hint: Tooltip — verfügbar für alle Elementtypen, nicht nur numerische.

Typen innerhalb einer einzigen Property mischen

Im Gegensatz zu INDI, wo ein Vektor nur einen einzigen Elementtyp enthält, kann eine OST-Property unterschiedliche Typen frei mischen:

"editabledata": {
  "permission": 2,
  "e": {
    "bool1":   { "type": "bool",   "directedit": true },
    "string1": { "type": "string", "directedit": true },
    "int1":    { "type": "int" },
    "float1":  { "type": "float" },
    "date1":   { "type": "date",   "directedit": true }
  }
}

directedit:true vs. directedit:false

  • directedit:true: der Client editiert das Element einzeln und sendet es allein (SV) — sofort angewendet.
  • directedit:false: das Element kann nur über einen gruppierten Versand der gesamten Property geändert werden (SA) — alle editierbaren Elemente der Property müssen in diesem Versand enthalten sein, sonst wird nichts angewendet. Auf der Seite eines typischen Clients entspricht das zwei unterschiedlichen Darstellungen: ein Steuerelement für sofortige Bearbeitung für jedes directedit:true-Element, und ein Formular mit “Speichern”-Button, das alle directedit:false-Elemente zusammenfasst.

Diese Unterscheidung ist unabhängig vom Typ: Im Beispiel oben lassen sich bool1/string1/date1 sofort bearbeiten, int1/float1 nur über das gruppierte Formular.