Hi,
das es hier mit sh.py weitergeht, wollte ich mal etwas anregen, was mir schon lange im Kopf rumschwirrt, von dem ich aber nicht weiß, wie man es realisieren könnte.
Im Prinzip ist es ein Kombi aus threshold und eval_trigger.
Mit threshold gibt man ja an, wann ein Item triggern soll. Das ist meiner Meinung nach aber zu kurz gedacht. In den meisten Fällen will ich nicht dem triggernden Item (also der Quelle) sagen, wann es triggern soll, sondern beim getriggerten Item (also am Ziel).
Natürlich kann man dann versuchen, ein komplexes eval am Zielitem zu formulieren oder eben eine Logik schreiben. Würde man aber direkt am eval_trigger die Triggerbedingung formulieren können, dann würde man sich viele komplexe evals bzw. triviale Logiken sparen können.
Ein triviales Beispiel (mit bisherigen Mitteln):
Mit dem obigen Codeschnipsel kann ich beim Einschalten irgendwas machen, beim Ausschalten irgendwas anderes.
Gleiches Beispiel mit Bedingung im eval_trigger :
Über die Notation müsste man sich sicherlich noch Gedanken machen, ich sehe 2 naheliegende Varianten:
Variante 2 ist mächtig, aber man kommt da wieder in die python syntax rein, was es für Gelegenheitsbenutzer schwieriger macht.
Eine "Kür" wäre, wenn man auch noch den value des Triggers überschreiben könnte um einen eval komplett überflüssig zu machen, im obigen Beispiel:
Die angedachte Semantik: Trigger mich mit dem Wert 1 wenn das triggernde Objekt den Wert 0 hat.
Mir ist klar, dass diese Erweiterung den eval und die Logiken nicht ersetzen kann - soll sie aber auch nicht. Ich glaube, dass man aber hiermit weniger triviale Logiken bekommt und die Anzahl an Hilfsitems reduzieren kann.
Mir ist auch klar, dass das obige Beispiel trivial ist, ich habe aber gerade kein komplexeres parat. Wenn ich wieder mal über ein komplexeres Beispiel stolpere, werde ich es hier mal Posten.
Ich wollte das mal loswerden, vielleicht sieht noch jemand den Bedarf...
Gruß, Waldemar
das es hier mit sh.py weitergeht, wollte ich mal etwas anregen, was mir schon lange im Kopf rumschwirrt, von dem ich aber nicht weiß, wie man es realisieren könnte.
Im Prinzip ist es ein Kombi aus threshold und eval_trigger.
Mit threshold gibt man ja an, wann ein Item triggern soll. Das ist meiner Meinung nach aber zu kurz gedacht. In den meisten Fällen will ich nicht dem triggernden Item (also der Quelle) sagen, wann es triggern soll, sondern beim getriggerten Item (also am Ziel).
Natürlich kann man dann versuchen, ein komplexes eval am Zielitem zu formulieren oder eben eine Logik schreiben. Würde man aber direkt am eval_trigger die Triggerbedingung formulieren können, dann würde man sich viele komplexe evals bzw. triviale Logiken sparen können.
Ein triviales Beispiel (mit bisherigen Mitteln):
Code:
[Button] type = bool name = Tastendruck [OnTrue] type = bool name = Mach was beim Einschalten enforce_updates = true eval = 1 if value == 1 else None eval_trigger = Button [OnFalse] type = bool name = Mach was beim Ausschalten enforce_updates = true eval = 1 if value == 0 else None eval_trigger = Button
Gleiches Beispiel mit Bedingung im eval_trigger :
Code:
[Button] type = bool name = Tastendruck [OnTrue] type = bool name = Mach was beim Einschalten enforce_updates = true eval_trigger = Button [COLOR=#0000FF]== 1[/COLOR] [OnFalse] type = bool name = Mach was beim Ausschalten enforce_updates = true eval = 1 eval_trigger = Button [COLOR=#0000FF]== 0[/COLOR]
- Wert < Item < Wert bzw. Item == Wert (oder wie bisher nur Item ohne Vergleich)
- Kompletter boolescher Ausdruck in python syntax
Variante 2 ist mächtig, aber man kommt da wieder in die python syntax rein, was es für Gelegenheitsbenutzer schwieriger macht.
Eine "Kür" wäre, wenn man auch noch den value des Triggers überschreiben könnte um einen eval komplett überflüssig zu machen, im obigen Beispiel:
Code:
[OnFalse] type = bool name = Mach was beim Ausschalten enforce_updates = true eval_trigger = Button[COLOR=#0000FF](1) == 0[/COLOR]
Mir ist klar, dass diese Erweiterung den eval und die Logiken nicht ersetzen kann - soll sie aber auch nicht. Ich glaube, dass man aber hiermit weniger triviale Logiken bekommt und die Anzahl an Hilfsitems reduzieren kann.
Mir ist auch klar, dass das obige Beispiel trivial ist, ich habe aber gerade kein komplexeres parat. Wenn ich wieder mal über ein komplexeres Beispiel stolpere, werde ich es hier mal Posten.
Ich wollte das mal loswerden, vielleicht sieht noch jemand den Bedarf...
Gruß, Waldemar