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

[rudolfkoenig]

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

Man clickt auf "set" neben dem voreingestellten copyGplotFile.

[betateilchen]

ME sollten die Templates und Vorlagen ohne dieses readonly daherkommen, damit man überhaupt etwas damit anfangen kann

Abgesehen davon, dass template und Vorlage das gleich ist, geht es genau darum, diese Vorlagen als solche in ihrem Bestand zu sichern.

Um eine Vorlage für eigene Zwecke zu benutzen, ist set ... copyGplotFile eigentlich schon immer der dafür vorgesehene Weg. Diese Funktion wurde jetzt nicht neu eingeführt. In der Kopie der Datei ist das readonly nicht mehr vorhanden, somit kann der Anwender damit tun und lassen, was er möchte.

[tryit]

Ein liebes Danke an rudolfkoenig!

... darauf wäre ich im Leben nicht gekommen, weder aus der Commandref zu SVG "Set copyGplotFile" noch aus vorliegendem Thread. (War - und ist - für mich unlogisch, warum ich eine neu angelegte .gplot Datei nicht einfach speichern (Write .gplotfile) können sondern erst kopieren soll)
Ohne "readonly" hatte das Speichern bei mir immer funktioniert, ohne dass ich je eine Datei zerschossen hätte.
Aber mit dem "Set copyGplotFile" kann man ja gut leben.

Ergibt sich für mich die Anschlussfrage: Wie oder wo ist "die aktuell ausgewählte .gplot Datei" definiert?

@betateilchen:
Ich unterscheide zwischen gelieferten "Templates" und eigenen "Vorlagen", die ich nach Bedarf ganz oder teilweise meinen .gplot inkorporiere - und auch hier noch einmal: ich habe es noch nicht fertiggebracht, eine *.gplot zu zerschießen (mehrfach genutzte .gplot haben zusätzlich zu dem ohnehin vorhandenen Warnhinweis bei mir eine Namenspräambel, so dass ich gar nicht auf die Idee komme, diese im Editor zu öffnen.

[rudolfkoenig]

Ohne "readonly" hatte das Speichern bei mir immer funktioniert, ohne dass ich je eine Datei zerschossen hätte.

Zerschiessen ist Ansichtssache, aus meiner Sicht als Softwarelieferant ist das der Fall.
Dafuer repariert das naechste FHEM Update das Problem, was vermutlich der Benutzer als Zerschiessen wertet.

[betateilchen]

unlogisch, warum ich eine neu angelegte .gplot Datei nicht einfach speichern (Write .gplotfile) können sondern erst kopieren soll

Wird eine "neue" gplot Datei mit FHEM Bordmitteln erzeugt, sollte diese nicht schreibgeschützt sein und kann sofort verwendet werden.

Ergibt sich für mich die Anschlussfrage: Wie oder wo ist "die aktuell ausgewählte .gplot Datei" definiert?

Die gplot Datei, die für set ... copyGplotFile als Quelle verwendet wird, ist die Datei, die aktuell im gplot Editor geladen ist. Diese ergibt sich aus dem im DEF des SVG devices angegebenen Dateinamen.

define <name> SVG <logDevice>:<gplotfile>:<logfile>

Wird diese Datei mit set ... copyGplotFile kopiert, wird automatisch der Name der neuen Datei in das DEF des SVG device übernommen und im Editor angezeigt.

Das sind alles bewährte und durchdachte Mechanismen, die es schon ewig gibt, die aber die wenigsten Benutzer kennen, geschweige denn in der Vergangenheit genutzt haben.

[tryit]

Danke betateilchen!
Mit jeder Antwort erhellt sich mir die Struktur des Systems etwas mehr...

Zitat

    define <name> SVG <logDevice>:<gplotfile>:<logfile>


Wird diese Datei mit set ... copyGplotFile kopiert, wird automatisch der Name der neuen Datei in das DEF des SVG device übernommen und im Editor angezeigt.

Das sind alles bewährte und durchdachte Mechanismen, die es schon ewig gibt, die aber die wenigsten Benutzer kennen, geschweige denn in der Vergangenheit genutzt haben.

So habe ich schon immer meine SVG's angelegt!

[betateilchen]

So habe ich schon immer meine SVG's angelegt!

So habe ich in all den vielen Jahren noch nie ein SVG angelegt.
Ich benutze immer den Link "Create SVG Plot from..." im Log-Device als Startpunkt