[gelöst] 98_SVG.pm - gplot file als readonly markieren

Begonnen von betateilchen, 04 März 2022, 08:40:04

Vorheriges Thema - Nächstes Thema

betateilchen

Hallo Rudi,

seit langem ärgere ich mich immer wieder darüber, dass der gplot Editor bei komplexen gplot-Dateien komplett versagt und diese Dateien regelmäßig "versehentlich" zerstört.
Mit "komplex" meine ich z.B. mehr als 2 y-Achsen, plotFunctions in Kombination mit DbLog usw. Diese Dateien können nur über "Edit files" korrekt bearbeitet werden.
Das Schreiben solcher Dateien wird ja schon dadurch ausgelöst, dass man nicht aufpaßt und durch Drücken von ENTER das Formular im gplot Editor abgeschickt und das gplot file geschrieben wird.

Um das zu verhindern, habe ich mir einen patch gebaut, der das Schreiben eines gplot Files aus dem gplot Editor verhindert, wenn es eine Zeile mit dem Inhalt "#readonly" enthält:


# Created by FHEM/98_SVG.pm, 2022-03-04 08:17:03
#readonly
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
...


Mein Bestreben war, die Änderungen in 98_SVG.pm möglichst gering zu halten.
Falls Du eine andere/bessere Idee hast, wie man das Feature umsetzen kann, gerne  :)


Index: 98_SVG.pm
===================================================================
--- 98_SVG.pm   (revision 25766)
+++ 98_SVG.pm   (working copy)
@@ -59,6 +59,7 @@
   Jan=>"Jan", Feb=>"Feb", Mar=>"Mrz", Apr=>"Apr", May=>"Mai", Jun=>"Jun",
   Jul=>"Jul", Aug=>"Aug", Sep=>"Sep", Oct=>"Okt", Nov=>"Nov", Dec=>"Dez"
);
+my $gplotReadonly;

#####################################
sub
@@ -663,6 +664,14 @@
   return if($FW_hiddenroom{detail});
   return SVG_showData() if($FW_webArgs{showFileLogData});

+  if ($gplotReadonly) {
+    $FW_RET .=
+      '<div id="errmsg">'.
+        "gplot file marked as readonly: won't write!".
+      '</div>';
+    return 0;
+  }
+
   if(!defined($FW_webArgs{par_0_0})) {
     $FW_RET .=
       '<div id="errmsg">'.
@@ -793,6 +802,7 @@
     }
   };

+  $gplotReadonly = 0;
   foreach my $l (@svgplotfile) {
     $l = "$l\n" unless $l =~ m/\n$/;

@@ -806,6 +816,8 @@
       }
     } elsif($l =~ "^plot" || $plot) {
       $plot .= $l;
+    } elsif($l =~ "^#readonly") {
+      $gplotReadonly = 1;
     } else {
       push(@data, $l);
     }
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Ich wuerde das lieber als Attribut machen, dann gibt es gleich die Doku dazu.
Was dagegen?

Beta-User

Vorschlag: beide Ansätze kombinieren?

Hintergrund: Es gibt ja z.B. für Heizungs-Thermostate "Standard-gplot"-Files, die für alles mögliche taugen. Wenn der User die versehentlich überschreibt (ist mir früher auch schon passiert), ist das "doof".

Die Logik wäre: Attribut überschreibt die Vorgabe aus dem file.

Ach ja: Danke für den Vorschlag zu readonly!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

#3
Zitat von: rudolfkoenig am 04 März 2022, 12:20:03
Was dagegen?

Ja, denn ein gplot file besitzt keine Attribute und wird ggf. auch in mehreren devices verwendet.
Wo willst Du da ein Attribut setzen, um das gplot file selbst zu schützen?

Standardmäßig soll in einem von FHEM ausgelieferten gplot file überhaupt kein readonly gesetzt werden, weil es da normalerweise nicht notwendig ist bzw. sich diese Datei auch jederzeit problemlos wiederherstellen lässt.

Da ich aber nicht mit den standardmäßig gelieferten gplot arbeite, möchte ich zumindest die Möglichkeit haben, bestimmte (!) von mir erstellte gplot Dateien entsprechend zu schützen. Letzte Nacht habe ich gerade mal wieder zwei Stunden damit zugebracht, solche versehentlich verursachten Probleme zu beseitigen.




Edit:

Zitat von: rudolfkoenig am 04 März 2022, 12:20:03
dann gibt es gleich die Doku dazu.

Das Ansinnen ist löblich.
Aber: der Aufbau der gplot Dateien ist ohnehin nirgends wirklich nachvollziehbar beschrieben, das erschließt sich einem entweder durch trial-and-error oder indem man sich den Code von 98_SVG.pm vornimmt und die Bedeutung des Dateiinhaltes verinnerlicht.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

ZitatJa, denn ein gplot file besitzt keine Attribute und wird ggf. auch in mehreren devices verwendet.
Falls mehrere SVGs die gleiche .gplot verwenden, wird im SVG Editor eine Warnung eingeblendet, diesen Fall sehe ich nicht, bzw. es wird sehr kompliziert.

ZitatWo willst Du da ein Attribut setzen, um das gplot file selbst zu schützen?
Ist wohl eine rhetorische Frage: in der SVG, was die Datei verwendet.
Allerdings ist das nicht naheliegend, weil der Benutzer die Datei direkt editiert, d.h das Attribut kann ich mir sparen.

Auf der anderen Seite sollten alle ausgelieferten .gplot Dateien sollten mit #readonly versehen werden, das wuerde immerhin die Aenderung ueber den PlotEditor vermeiden. Und das Faeture waere damit fuer die Datei-Editierer dokumentiert.

betateilchen

Zitat von: rudolfkoenig am 04 März 2022, 13:51:41
Falls mehrere SVGs die gleiche .gplot verwenden, wird im SVG Editor eine Warnung eingeblendet, diesen Fall sehe ich nicht, bzw. es wird sehr kompliziert.

Das hindert den gplot-Editor nicht daran, das file zu überschreiben. Was sich dann auf alle SVG devices auswirkt

Zitat von: rudolfkoenig am 04 März 2022, 13:51:41
Ist wohl eine rhetorische Frage: in der SVG, was die Datei verwendet.

Ja, schon. Aber wenn 5 SVG die gleiche Datei verwenden, muss auch in allen 5 SVG das Attribut gesetzt werden, damit es wirklich zuverlässig wirkt.

Zitat von: rudolfkoenig am 04 März 2022, 13:51:41
Auf der anderen Seite sollten alle ausgelieferten .gplot Dateien mit #readonly versehen werden,
das wuerde immerhin die Aenderung ueber den PlotEditor vermeiden.

Wenn Du das für sinnvoll hältst, gerne.

Gerade getestet: set <dev> copyGplotFile funktioniert mit meiner vorgeschlagenen Änderung nach wie vor problemlos. Das neue gplot File ist dann auch wieder readonly.

Zitat von: rudolfkoenig am 04 März 2022, 13:51:41
Und das Feature waere damit fuer die Datei-Editierer dokumentiert.

Na immerhin  :)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Ich habe jetzt eine SVG.pm Version eingecheckt was eine readonly Anweisung in der .gplot File beruecksichtigt.

Ich habe aber statt #readonly den Weg ueber "set readonly" gewaehlt.
Vorteile: keine globale Variable, und der Patch ist deutlich kleiner. Nachteil: nicht gnuplot kompatibel.

Falls kein Veto kommt, dann wuerde ich alle eingecheckten .gplot Dateien mit dieser Zeile versehen.
Damit man diese Dateien anpassen kann, filtert "copyGplotFile" die "set readonly" Zeile.

betateilchen

Hallo Rudi,
danke für die Umsetzung. Die neue Version habe ich gerade getestet und zwei Anmerkungen.


  • Wenn man im gplot-Editor jetzt nach Änderungen ENTER drückt (langjährige Angewohnheit, vermutlich nicht nur bei mir) wird FW_submit() für die Ausgabe der preprocessed data aufgerufen. Könnte man nicht stattdessen ein FW_submit() aufrufen, das einfach nichts tut oder nur die Meldung auf das readonly nochmal ausgibt? Ich glaube, das wäre besser verständlich. Bisher wurde in dem Fall immer FW_submit() mit "write gplot file" als default aufgerufen.
  • bei "set <dev> copyGplotFile" wird ein readonly file nicht kopiert, wenn es "already unique" ist. Man müsste also zwingend erstmal das gplot file manuell bearbeiten. Bei selbst erstellten Dateien finde ich das ok, aber wenn sich nun alle von FHEM ausgelieferten gplot Dateien erstmal nicht mit FHEM Bordmitteln bearbeiten lassen, sind die (berechtigten) Beschwerden der Benutzer absehbar.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Ad 1: ich finde beide Varianten (meine und dein Vorschlag) komisch.
Richtig waere alle Felder auf readonly zu setzen, und das habe ich jetzt auch gemacht.
Return bringt aber weiterhin das "Show preprocessed input" Dialog :)

Ad 2: unique ist eine .gplot Datei dann, wenn es genauso heisst, wie das SVG. Das sollte im Fall der ausgelieferten Dateien kein Problem sein, wenn doch, dann muss man eine groessere Runde drehen.

betateilchen

#9
Zitat von: rudolfkoenig am 05 März 2022, 13:03:12
Return bringt aber weiterhin das "Show preprocessed input" Dialog

Das halte ich persönlich für die schlechteste mögliche Lösung  :(
Die zwischenzeitlich eingecheckte Lösung #25781 mit der Fehlermeldung als Rückgabewert fand ich erheblich besser.

Überlegung zur Logik: Wenn alle Felder im Editor readonly sind, braucht man auch die "prepocessed data" nicht mehr, weil man ohnehin nichts verändern kann, was sich auf die Ausgabe auswirken würde.
(doch, die kann man u.U. trotzdem brauchen)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

ZitatDas halte ich persönlich für die schlechteste mögliche Lösung  :(
Gibt es dafuer auch eine Begruendung?
Dass die zwischenzeitlich eingecheckte Loesung dir gefaellt, leuchtet mir ein, entspricht ja auch deinem Vorschlag.
Mein Problem damit: dem Benutzer wird das Aendern der Konfiguration erlaubt, und beim Speichern mitgeteilt , dass Alles ueberfluessig war.

betateilchen

#11
Zitat von: rudolfkoenig am 06 März 2022, 10:30:50
Gibt es dafuer auch eine Begruendung?
Dass die zwischenzeitlich eingecheckte Loesung dir gefaellt, leuchtet mir ein, entspricht ja auch deinem Vorschlag.

Da geht es nicht um "meinen Vorschlag" (so eitel bin ich nicht), sondern darum, dass man sich als Benutzer in der Vergangenheit angewöhnt hat, im Editor auch mal ENTER zu drücken. Bisher wurde dann gespeichert und man konnte weitermachen. Das "preprocessed input" Popup muss man erst manuell wieder schließen. Außerdem ist das Fenster in vielen Fällen einfach gar nicht erwünscht.

Zitat von: rudolfkoenig am 06 März 2022, 10:30:50
Mein Problem damit: dem Benutzer wird das Aendern der Konfiguration erlaubt, und beim Speichern mitgeteilt , dass Alles ueberfluessig war.

Das verstehe ich. Kannst Du die beiden Verhaltensänderungen nicht kombinieren? Du setzt die Felder auf readonly und falls jemand (gewohnheitsgemäß) ENTER drückt, kommt die Meldung trotzdem und verschwindet automatisch wieder. Meinetwegen kann das ENTER auch einfach "gar nichts" tun, ich brauche die Fehlermeldung nicht unbedingt. Aber ich will nicht durch ein unnötiges popup am Weiterarbeiten gehindert werden.

Zitat von: rudolfkoenig am 05 März 2022, 11:41:38
Falls kein Veto kommt, dann wuerde ich alle eingecheckten .gplot Dateien mit dieser Zeile versehen.

Soll ich Dir das abnehmen?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

ZitatKannst Du die beiden Verhaltensänderungen nicht kombinieren?
Ok, einigen wir uns auf unentschieden :)
Habs gemacht.


ZitatSoll ich Dir das abnehmen?
Danke, nicht noetig, ein
sed -i -e '/^set terminal/i set readonly' *.gplot
hat mir die Arbeit schon abgenommen.

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

tryit

Hallo in die Runde
Ob das jetzt so eine gute Idee war, die *.gplot mit dem Update alle auf readonly zu setzen, weiß ich nicht...

Gemerkt habe ich es freilich erst, als ich ein neues SVG einrichten wollte, und kläglich scheiterte:
In die Maske läßt sich schon nichts eintragen (1. Template-Eintrag ändern) geschweige denn läßt sich die Datei speichern (was ja noch logisch ist - folglich läßt sich aber dann auch nichts editieren) - Also erst einmal stundenlang das Dateisystem untersucht, schon an ein Hacking gedacht, dann einmal im Forum gesucht - und siehe da!

ME sollten die Templates und Vorlagen ohne dieses readonly daherkommen, damit man überhaupt etwas damit anfangen kann, bei besonderem Schutzbedarf kann man in eine ja ohnehin dann schon offene Datei dann manuell den Garant für's ewige Leben einsetzen.

Hat jemand eine Idee, wie ich diese readonly's wieder loswerde?

Danke im Voraus