Assistent?

[henfri]

Hallo,

erst einmal meinen Dank und meine Hochachtung denen, die die SmartVisu voran bringen.
Toll, was ihr leistet.

Gerade im Quad-Design gibt es einige sehr mächtige Widgets.
Dabei wird jedoch auch immer deutlicher, dass man mit dem Komma-Zählen an die Grenzen kommt:

{{ quad.color(id, item_value_r, item_value_g, item_value_b, min, max, step, colors, style, colormodel, linetext, item_switch_r, item_switch_g, item_switch_b, min_display, max_display, item_uzsu, uzsu_attribs, popupcolor, item_switch_ww, item_value_ww, item_plot, icon_plot, item_auto, extpopup, locks, item_seq, icon_color, place3, place4, column_order) }}

Wie schafft ihr es da, keinen Fehler zu machen?

Ich frage mich, ob es nicht mit begrenztem Aufwand möglich wäre, einen Assistenten zu erstellen, der dabei hilft.
Gedanken, die ich hatte:
Smarthome.py kann ja im interaktiven Modus gestartet werden. Da hat man dann eine Python Shell in der Kommandovervollständigung geht. Damit könnte man einen Dialog machen:
Select widget
quad.color
ID?
Mein Widget
item_value_r (an item for the red value in RGB model or hue in HSL and HSV model, or single item containing list of all color values)?
eg.bad.rgb.r

Und bei den Eingaben des Users würde TAB automatisch das Item vervollständigen. Die Eingaben des Users können auch auf Plausibilität und Syntax geprüft werden.

Noch schöner wäre es natürlich im WebIF - aber sicher auch aufwändiger.


Ein anderer Gedanke war die Auto-Generierung.
Ich glaube, dass ich die momentan nicht nutzen kann, denn dafür müssen ja die Item-Bäume strukturiert sein, wie die Visu-Seiten. Eine Seite mit allen Lichtern geht dann nicht, glaube ich, oder?


Schließlich habe ich auch schon überlegt, Excel zu nutzen, um zumindest das Komma-Zählen loszuwerden...


Mich würde interessieren, ob ich der Einzige bin, der Probleme hat und ob es Überlegungen in die Richtung oben gibt?

Gruß,
Hendrik

[Onkelandy]

Hi!
Ne, ich habe selbst immer Probleme, auch bei den normalen Widgets. Kopiere mir halt immer den Syntax aus der Docu Seite über meinen Eintrag und zähl dann durch. Aber ich bin da voll bei dir, ekelhaft! Wir haben das sogar schon auf dem Radar für einen nächsten Release.
Persönlich ist mir die Autogenerierung der Seiten zu unflexibel, weshalb ich dafür auch nicht wirklich Zeit aufwenden möchte. Aber einen netten grafischen Editor mit Drag and Drop oder betitelten Spalten a la Excel wäre sinnvoll.

Konkrete Lösungsansätze hätte ich programmiertechnisch aktuell keine, vielleicht hat sonst wer ne Idee.. Würde blockly für sowas funktionieren? Also zumindest zum Zusammenstecken von mehreren Widgets in Blocks oder so..?

[Tom Bombadil]

Kopiere mir halt immer den Syntax aus der Docu Seite über meinen Eintrag und zähl dann durch.

So mache ich es auch. Allerdings habe ich mittlerweile auch Widgets (inbesondere Plots), die ich bewusst auf mehrere Zeilen aufsplitte, um die Übersicht nicht zu verlieren.

Konkrete Lösungsansätze hätte ich programmiertechnisch aktuell keine

Vielleicht eine Art "Property-Editor", wie ihn die meisten modernen IDE's kennen (--> rechte Maustatste --> 2-spaltige Property-Liste des Widgets erscheint als Tabelle (Name+Wert), die gewünschten Properties können dann befüllt werden). Sowas ließe sich vielleicht als zentrale Routine bauen, die Widgets müssten dann aber irgendwo ihre Properties an die Liste mitteilen können.

Nur mal so in's Blaue geschossen ...

/tom

[Onkelandy]

Tom, was wäre da der technische Ansatz? Im Endeffekt bräuchte es ja tatsächlich eine eigene Konfiguratorseite, wo man sich die Widgets zusammenschustern kann. Vielleicht wäre es ja schon ausreichend, zuerst über ein Dropdown das Widget zu wählen und dann aus den Parameter-Infos eine Tabelle auf der Seite zu generieren. Diese füllt man dann aus, klickt auf "Genereate Widget" und erhält einfach den fertigen Widgetcode, den man dann manuell in seine Seite einfügt. Scheint mir am realistischsten zu sein, nä?

Möglicherweise könnte man auch einfach die aktuelle Dokuseite nutzen, um dort interaktiv ein Widget zu erstellen, zumal dort ja die ganzen Parameter schon vorhanden sind. Oder man baut auf dem Templatechecker was auf..?

[Tom Bombadil]

Die 'Spontanidee' war eigentlich viel einfacher. Der Aufruf der 'Widgets' bleibt wie gehabt im HTML (bzw. Verweise auf die Widgets), die Eigenschaften wandern in eine zentrale 'Datenbank' (kann xml file/csv/sqlite/wasauchimmer sein). Die Bearbeitung der Widget-Eigenschaften erfolgt im normalen Output per rechter Maustaste, gefolgt von F5.

Vermutlich würde man dann aber für die Anzeige der Widgets wieder Unique ID's einführen müssen, aber das haben die meisten bestehenden Visu's vermutlich eh noch drin.

Das ist nicht ganz das, was henfri vorschwebt (kompletter visueller drag&drop Editor). Aber zumindest ein vereinfachender Zwischenschritt, bis jemand eine bessere Idee hat. Ich bin zu lange aus der aktiven Programmierung raus, um die aktuell technischen Möglichkeiten zu kennen. Aber ich vermute, ein drag&drop Editor, der beliebiges bestehendes HTML liest und auch wieder sicher wegschreibt, übersteigt unsere Programmierkapazitäten.

/tom

[Bonze]

Eine grafische programmierung geht vielleicht mit ner bibliothek ala https://visjs.org/ , zumindest meine ich soetwas da schonmal gesehen zu haben.
https://visjs.github.io/vis-network/...ionEvents.html

[henfri]

Hallo,

ich denke, die erste Frage ist, ob die Items des Backends unterstützt werden sollen.
Dann muss ja nicht nur die Syntax der Widgets, sondern auch die verfügbaren Items (und ggf. ihr Typ) verfügbar sein.

Was meint ihr?

Wenn wir uns auf sh.py einschränken, dann gibt es da ja im Admin-Interface schon eine entsprechende Infrastruktur mit Auto-Vervollständigung der Items.

Vielleicht als Inspiration:
https://www.openhab.org/docs/configuration/editors.html
https://github.com/openhab/openhab-v...ster/README.md
http://www.kaikreuzer.de/2017/12/18/openhab22/
Das ginge dann generisch, nicht nur für Sh.py

Hier noch Gedanken dazu:
https://github.com/smarthomeNG/smarthome/issues/266


Gruß,
Hendrik

[Onkelandy]

Hm, das ist auch ein interessanter Ansatz - würde ich mich aber der Message von bmxp anschließen
Was ich mir am ehesten vorstellen könnte, wäre eine automatisch generierte Tabelle auf den einzelnen Widget Dokuseiten, wo man sich dann den Code "piece by piece" erstellen lassen kann. Ist sicher nicht megaschnell und easy, könnte trotzdem sehr hilfreich sein, denk ich.

[Tom Bombadil]

Was ich mir am ehesten vorstellen könnte, wäre eine automatisch generierte Tabelle auf den einzelnen Widget Dokuseiten, wo man sich dann den Code "piece by piece" erstellen lassen kann.

Ok, ich konkretisiere mal, hab noch ein bisschen gedanklich drauf rumgekaut (hat auch nicht weh getan ):

• das alte HTML-Grundgerüst bleibt im Grunde bestehen,
• der Aufruf der Widgets wird reduziert auf basic.widget(unique-id, bezugsitem),
• jedes Widget enthält seine bekannten Parameter (ist heute schon durch konsequentes @param im Header aller Widgets gegeben - siehe Beispiel):
  /**
  * Displays a flip-switch
  *
  * @param {id=} unique id for this widget (optional)
  * @param {item} an item
  * @param {text=On} text for the 'on' state (optional, default 'On')
  * @param {text=Off} text for the 'off' state (optional, default 'Off')
  * @param {text=1} value for the 'on' state (optional, default 1)
  * @param {text=0} value for the 'off' state (optional, default 0)
  */
  {% macro flip(id, item, txt_on, txt_off, val_on, val_off) %}
  [...]
  {% endmacro %}
• beim Aufruf der html-Seite wird eine gleichnamige xml-Datei mit den Properties aller Widgets eingelesen (zentrale Systemfunktion).

Nehmen wir an, es gibt eine neue config-Variable "config_mode=True".

Ist diese eingeschaltet, gibt es eine weitere zentrale Systemfunktion, die bei Rechtsklick auf ein Widget eine Tabelle mit allen @param's (im "IDE Property Style") hervorbringt - linke Spalte Name, rechte Spalte änderbarer Wert, unten die Buttons Save/Cancel. Save speichert die Widget-Einstellungen zurück in die XML-Datei, die ja genauso heißt wie die aktuelle Seite.

Damit ließe sich das Ganze einigermaßen komfortabel und mit einer überschaubaren Anzahl an neuen, zentralen Systemfunktionen realisieren. Der Rest bleibt sogar gleich (HTML-/TWIG-Grundgerüst) - ist berdeutlich übersichtlicher zu lesen/schreiben. Und man könnte die Visu sogar abwärtskompatibel fahren (neue config-Variable enable_new_syntax=True schaltet auf die kurze Schreibweise der Widgets wie oben genannt um; sonst wird die alte, lange Schreibweise verwendet).

Wie gesagt, nur mal so ein paar Gedanken; kann natürlich auch sein, dass ich mir das zu einfach vorstelle.

/tom

p.s. Obige Darstellung bezieht sich natürlich auf die Originalanfrage von henfri, wie man die Anzahl der Kommas in den Widgets reduzieren kann. Mit einer kompletten grafischen Designoberfläche hat das natürlich wenig zu tun, ist aber vielleicht ein Anfang.

[henfri]

Hallo,

es ist klar, dass der Aufwand im Verhältnis zum Nutzen liegen muss. Und da ist eine 'kleine' Lösung sicher das Richtige.

Was ich mir jedoch noch wünschen würde, ist dass man eine Liste an Items aus dem Backend exportieren kann, die dann in dem Property-Editor als Vorschlag auswählbar ist (Tipp, Tab (Autovervollständigung), Tip, Tab usw.)).

Gruß,
Hendrik

[Tom Bombadil]

Nachtrag - die Tabelle beim Rechtsklick muss natürlich nicht in-place hervorpoppen, sondern kann auch überlappend am linken oder rechten Rand dargestellt werden. Dafür gibt es Standardfunktionen in jQuery, man muss da nichts neu programmieren - ich nutze das z.B., um mein Seitenmenü darzustellen:

1_1.png 2_1.png

/tom

[Tom Bombadil]

Was ich mir jedoch noch wünschen würde, ist dass man eine Liste an Items aus dem Backend exportieren kann, die dann in dem Property-Editor als Vorschlag auswählbar ist (Tipp, Tab (Autovervollständigung), Tip, Tab usw.)).

Nur, dass ich es verstehe: Du meinst, die ausgewählten Items z.B. am Ende des aktuellen HTML automatisch einzufügen (in-place geht vielleicht auch, dürfte aber deutlich schwieriger sein)? Aber als was, bzw. als Bestandteil welchen Widgets? Plot, switch, flipswitch, colordisk ... ???
/tom

[henfri]

Hallo,

nein, das meine ich anders.
Wenn man einen Parameter innerhalb des Property-Editor eingibt, dann wäre es super, wenn der User assistiert wird:
a) Bei einem Property, welches nur vorgegebene Werte haben kann (hsv oder rgb z.B.) gibt es ein Drop-Down Menü. Hier kann man aus den Parametern wählen
b) Bei einem Property, welches ein Item zugewiesen bekommt, bekommt man eine Auswahl:Autovervollständigung.gif

So war das gemeint.

Noch ein Gedanke: Oft wird man ein Widget ändern wollen. Man sollte also ein Widget auch in den Editor laden können und dann z.B. in meinem Beispiel oben Wohnzimmer durch Esszimmer ersetzen können - das wäre aber schon eher Richtung Kür.

Gruß,
Hendrik

[PatrikG]

Wem eine einfache optische HIlfestellung reicht und mit Notepad++ arbeitet, der kann auch die AutoCompletion-Funktion von Notepad++ aktivieren und muss dazu dann lediglich die Datei "%programfiles%\Notepad++\autoCompletion\html. xml" anpassen. Dort muss "nur" für jede Funktion nur ein entsprechender Keyword-Eintrag erstellt werden. Als Beispiel mal der für die Checkbox:

<KeyWord name="checkbox" func="yes">
   <Environment terminal="" />
   <Overload retVal="basic" descr="Displays a checkbox">
      <Param name="[id]" />
      <Param name="item" />
      <Param name="[txt]" />
      <Param name="[val_on=1]" />
      <Param name="[val_off=0]" />
   </Overload>
</KeyWord>

Das würde dann so aussehen:
autocompletition.png

[Onkelandy]

Ähnliche Autocomplete Funktionen gäbs wohl auch für Atom. Wäre auch ein interessanter Ansatz, der sich halbwegs realistisch umsetzen ließe. Müsste man halt automatisiert die bestehenden Infos aus den Widgets, so wie sie für die Doku genutzt werden, in ein XML schreiben lassen.