Parametererklärungen für die SF Doku

[swiss]

Hallo zusammen.

Ich versuche heir mal die Einzelnen in der Comet Visu möglichen Parameter und Funktionen zusammen zu tragen um daraus in einem zweiten Schritt eine möglichst volltständige Parameterbeschreibung im SF Wiki anzulegen. Hier mal dass das ich bis jetzt zusammen getragen haben.

Anregungen, Änderungen und Ergänzungen sind ausdrücklich erwünscht!


Die einzelnen Parameter im Überblick:

align: (left, right, center) Bestimmt die Position des Textest z.B. innerhalb einer Schaltfläche

name, text-content, label: Anzeigename des Elementes

maping: Mit maping kann man die Anzeige von Werten und Zuständen maskieren. z.B. 0 wird als AUS angezeigt und 1 als EIN

adress: Hier werden die Gruppenadressen angelegt, die mit diesem Element verknüpft werden sollen.

flavour: ???

styling: vordefinierte Farbschemas für Schaltflächen usw... z.B. Rot/Grün

min: minimaler Wert z.B. 0

max: maximaler Wert z.B. 255

step: Schrittgrösse zwischen 2 Werten z.B. 1

src: Pfad zu einer Datei.

width: Breite eines Elements in Pixel z.B. 800

height: Höhe eines Elements in Pixel z.B. 300

refresh: Aktualisierungsrete in sekunden z.B. 10

frameborder: (yes/no) Einstellung ob um ein Element einen Rahmen angezeigt werden soll oder nicht.

background: Hintergrundfarbe eines Elementes.

rrd: Hier wird der Dateiname OHNE ENDUNG .rrd eingegeben. z.B. 28.D0327E020000_temp

unit: Mit diesem Parameter wird die Masseinheit festgelegt. z.B. °C

series: (hours/days/weeks/months/years) Legt fest für welchem Zeitraum die Grafik dargestellt werden soll.

period: Erweitert die Angabe zum Zeitraum der Darstellung. z.B. 7

datasource: (Min/Avg/Max) Legt fest ob der Minimal-, Durchschnitts- oder Maximalwert dargestellt werden soll.

[Chris M.]

Mapping und Styling wird am Anfang der Config-Datei definiert. (Z.Zt. nur per Hand, der Editor kann das nicht ändern, aber durchaus weiterverwenden).
In der Config-Demo steht z.B.:

    <mappings>
      <mapping name="OpenClose">
        <entry value="0">zu</entry>
        <entry value="1">offen</entry>
      </mapping>
      <mapping name="OnOff">
        <entry value="0">Aus</entry>
        <entry value="1">An</entry>
      </mapping>
      <mapping name="Sign">
        <entry range_min="-1e99" range_max="0">Negativ</entry>
        <entry value="0">Null</entry>
        <entry range_min="0" range_max="1e99">Positiv</entry>
      </mapping>
      <mapping name="KonnexHVAC">
        <entry value="auto">Auto</entry>
        <entry value="comfort">Komfort</entry>
        <entry value="standby">Stand By</entry>
        <entry value="economy">Economy</entry>
        <entry value="building_protection">Haus-Schutz</entry>
      </mapping>
    </mappings>

So wird beim "OpenClose" Mapping dem KNX-Wert 0 die Anzeige "zu" zugeordnet.

[swiss]

Danke für die Ergänzung. Dann ist schon wieder etwas mehr klar.

[Chris M.]

Was ich mir vorstellen könnte, wäre im "attributes"-Bereich eines Widgets ein zusätzliches Element Namens "description" hinzuzufügen und so im Code und für den Editor sichtbar eine Kurz(!)beschreibung zu hinterlegen.

Nachteil: höherer RAM-Verbrauch auf Rechnern die eh niemals editieren werden.

Wie ist da die allgemeine Meinung zu?

Beispiel (lustlos):

attributes: {
  on_value:   { type: 'string'  , required: false, description: "Wert bei An" },
  off_value:  { type: 'string'  , required: false, description: "Wert bei Aus" },
  mapping:    { type: 'mapping' , required: false, description: "Mapping, halt" },
  styling:    { type: 'styling' , required: false, description: "Das Styling" },
  align:      { type: 'string'  , required: false, description: "Wo's hin soll" }
 },

[greentux]

Der RAM Bereich wiegt die Vorteile aus meiner Sicht mehr als auf.

[Chris M.]

Leider verstehe ich diesen Satz nicht.

Bist Du für diese Änderung oder gegen?

[greentux]

Ich bin dafür! In der Abwägung RAM Verbrauch vs. Doku gewinnt eindeutig die Doku.

[netzkind]

Problem: in welcher Sprache soll das sein?

[Chris M.]

Ich hätte Englisch gesagt - denn später (post 0.6.0) werden wir sowieso nach Locale entsprechend Übersetzungen einbauen müssen. Dann könnte der englische String als Aufhänger für die jeweiligen Übersetzungen dienen.

[swiss]

Hmmm...

Naja eine kurze Info hätte schon seine Vorteile. Allerdings ist eine gute Doku ohne hin wichtig und würde den Nutzen der Info etwas in Frage stellen.

PS: Ich hab mich heute ein bischen im SF Wiki ausgetobt. Allerdings nur im deutschen Benutzerhandbuch da ich leider nicht gut englisch kann Weitere Einträge werden folgen. Ich hoffe, dass ihr (die Entwikler) bei neuen Funktionen wie z.B. änderungen des "variant" in einem Widget hier kurz feedback geben könntet. Ich würde dass dann in die Doku einpflegen.

[Chris M.]

PS: Ich hab mich heute ein bischen im SF Wiki ausgetobt.

Sehr schön!

Ein Bitte jedoch: Wenn Du neue Seiten anlegst, dann bitte mit dem Prefix "CometVisu/" (also CometVisu/Benutzerhandbuch statt Benutzerhandbuch).
Das Wiki ist ja auch noch für ein paar andere Sub-Projekte da und so kommt man sich nicht in die Quere. Für'n Anwender kann man ja auch in der Anzeige der Links den Prefix weg lassen.
(Die bestehenden Seiten kann ich noch umbenennen)

Allerdings nur im deutschen Benutzerhandbuch da ich leider nicht gut englisch kann

Passt. Jeder macht halt das, was er gut kann.

Ich hoffe, dass ihr (die Entwikler) bei neuen Funktionen wie z.B. änderungen des "variant" in einem Widget hier kurz feedback geben könntet. Ich würde dass dann in die Doku einpflegen.

Das hoffe ich auch.
So wichtig dieses Thema ist, so schwierig da ungeliebt ist es auch. Daher scheue Dich bitte nicht einfach nachzufragen!

[swiss]

Ok. kannst du das mit den Präfix noch anpassen?

Ich habe für die deutschen Widget-Beschreibungen immer das Postfix (Deutsch) angehängt. Dann kann man die gleichen Namen auch für die englische Version nutzen.

z.B.

colorchooser -> für englisch
und
colorchooser (Deutsch) -> für das deutsche Handbuch

Danach hab ich einfach die Verweise maskiert dass im deutschen Handbuch der Link colorchooser auf colorchooser (Deutsch) verweist.

Gibt es noch weitere Dinge die man beachten sollte. Es sollte ja am Ende ein einheitliches Hanbuch werden. Gibt's da eine art knigge?

[Chris M.]

Ok. kannst du das mit den Präfix noch anpassen?

Erledigt

Ich habe für die deutschen Widget-Beschreibungen immer das Postfix (Deutsch) angehängt. Dann kann man die gleichen Namen auch für die englische Version nutzen.

Klingt erst mal gut. Evtl. hat ja jemand eine Ahnung, wie man beim MediaWiki "richtig" multilingual arbeitet und kann uns hier mal aufschlauen.

Gibt es noch weitere Dinge die man beachten sollte. Es sollte ja am Ende ein einheitliches Hanbuch werden.

Was ich mir noch wünschen würde, wäre auf einer Übersichtsseite (https://sourceforge.net/apps/mediawi...ditor_benutzen und https://sourceforge.net/apps/mediawi...u/XML-Elemente überschneiden sich da leicht) alle Widgets aufgeführt zu sehen und zu jedem einen kleinen Screenshot (ähnlich dem auf der ColorChooser Seite).
So kann ein Anwender auf einen Blick sehen, was es alles gibt.

Gibt's da eine art knigge?

Ich glaube, den darfst Du schreiben und daher dessen Inhalt maßgeblich bestimmen

[swiss]

Erledigt

Danke

Klingt erst mal gut. Evtl. hat ja jemand eine Ahnung, wie man beim MediaWiki "richtig" multilingual arbeitet und kann uns hier mal aufschlauen.

Das wäre wirklich interessant wobei man so zu Not auch auskommt

Was ich mir noch wünschen würde, wäre auf einer Übersichtsseite (https://sourceforge.net/apps/mediawi...ditor_benutzen und https://sourceforge.net/apps/mediawi...u/XML-Elemente überschneiden sich da leicht) alle Widgets aufgeführt zu sehen und zu jedem einen kleinen Screenshot (ähnlich dem auf der ColorChooser Seite).
So kann ein Anwender auf einen Blick sehen, was es alles gibt.

Ok ich nehme das mal noch auf die ToDo liste -> Wobei es gewisse Widget gibt, die man schlecht mit Screenshot's festhalten kann... z.B. Page oder Brake. Aber ich lasse mir was einfallen.

Ich glaube, den darfst Du schreiben und daher dessen Inhalt maßgeblich bestimmen

Na dann behalte ich das angefangene Schema mal bei. Somit entsteht auch ein habwegs einheitliches Erscheinungsbild.


Weiss eigentlich jemand, wie man im Wiki eine Navigation einbaut? Ich würde gerne irgend wie z.B. aus einer Widget-Beschreibung wieder zurück zur Übersicht springen können!?

[Chris M.]

Weiss eigentlich jemand, wie man im Wiki eine Navigation einbaut? Ich würde gerne irgend wie z.B. aus einer Widget-Beschreibung wieder zurück zur Übersicht springen können!?

Was immer geht: [[Category:CometVisu]] irgendwo (insb. unten...) auf die Seite schreiben.

Links die Menü-Struktur kann ich irgendwie auch anfassen, aber da suche ich mir jedes mal einen Wolf

Trick für Doofe ist jedoch irgendwo in den einleitenden Sätzen das Wort CometVisu zu gebrauchen und damit auf die Startseite zu verweisen...