User-Skin-Inhalte im Plugin prüfen, um nach einer PluginCode-Änderung einen GS zu verhindern?

  • Hallo


    Im Zuge der Anpassung des PluginHider-Plugins habe ich feststellen müssen, dass bei größeren Änderungen am Code und am Skin-Screen es bei Usern, welche noch den alten Skin-Screen nutzen, es mit dem aktualisierten Plugin zum Crash kommen kann.


    Sowas will man einem User ja aber nicht zumuten :winking_face:
    Bisher hilft da nur, einen neuen/anderen Screen-Namen zu verwenden.


    Nun wäre meine Frage, ob man zum Beispiel im Plugin-Code den Inhalt des zu verwendenden UserSkin-Screens abfragen kann.
    Also ob im zur Anwendung kommenden Skin-Screen ein widget "xxx" vorhanden ist und welche Attribute und Values gesetzt sind (renderer, source...).
    Darüber könnte man dann vielleicht gegensteuern und im Bedarfsfall auf den code-Internen Screen umschwenken, damit es zu keinem GS kommt.
    Vielleicht könnte man da sogar ein "Versionslabel" in den Plugin-SkinScreen reinnehmen. Und wenn die Version mit dem UserSkin nicht übereinstimmt, wird der interne Plugin-Screen genutzt. :winking_face:


    Wäre sowas möglich?
    Wenn ja, gibt es irgendwo einen Ansatz als Startpunkt?

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Ansatzpunkt:
    Ein Startplugin, dass keinen Skin hat und den aktuellen Skin checkt.
    Dann erst wird das eigentliche Plugin aufgerufen.


    In MerlinSkinThemes habe ich ein Startplugin (welches bei mir zu Laufzeit das aktuelle Plugin, falls eine neue *.py vorliegt, neu compiliert => pyo).
    Das kannst Du gerne verwenden und testen, ob das funktioniert.

  • Ok, Danke.
    Das schaue ich mir mal an.


    mit self.skin bekomme ich ja den im Plugin festgelegten Skin-Inhalt.


    In welchem Wert ist denn der tatsächlich eingelesene Skin abgelegt?


    self.parsedSkin klappt nicht.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Dem Skin plugindepends mitgeben können.
    Das heißt, anders wie bei Depends werden die nicht mitinstalliert.
    Es gilt als Überwachung. Ist das Plugin zu alt, wird es nicht installiert.

  • Das aktuelle Plugin würde ja mit einem Update von DMM auf der Box installiert werden.
    Das Problem ist der alte Skin-Screen in den Skin-Dateien des Users.


    Jetzt suche ich eine Möglichkeit, im Plugin den Inhalt des Userscreens analysieren zu können.


    Ich wollte jetzt ungern händisch die Skindateien scannen.


    Dachte, da gibt es im Plugin einen Wert, der den über Screen automatisch ermittelten Skin-Screen enthält.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Wenn ich den Inhalt des tatsächlich geladenen Skin-Screens kennen würde und sehe, dass der nicht passt, dann bräuchte man ja nur self.skinName ändern und schon wird der Plugin-interne Skin genutzte :winking_face:


    In irgendeiner Variablen muss doch der tatsächlich genutzte Skin-Screen gespeichert sein.


    In der Skin.py gibt es eine nette Zeile:
    myscreen = screen.parsedSkin = parsedSkin


    Jetzt wäre interessant, ob man im Plugin-Code an diese Werte kommt :winking_face:
    Stecken die evtl. irgendwo in self (Setup Screen) mit drin ?

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Ich glaub, ich hab die Lösung :winking_face:


    lookupScreen() lädt den tatsächlich verwendeten Screen.
    Wenn es den gibt, dann prüfe ich, ob im Skin das alte problematische widget "tabbar" enthalten ist.
    Wenn ja, wird einfach ein anderer self.skinName festgelegt, so dass der Plugin-interne neue Skin genommen wird.
    Ist das Feld nicht enthalten, wird es wohl bereits ein neuer Skin sein :winking_face:


    Die Funktion einfach im __init__ des Plugin-Screens aufrufen.
    self.check_Skin("widget","tabbar")

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

    7 Mal editiert, zuletzt von Sven H ()

  • Diese Version sollte jetzt bei allen Usern ohne GS wegen eines veralteten Skins funktionieren. :winking_face:


    Es wäre schön, wenn ihr das bei Euch mal testen könntet.
    Zum Test einfach diesen alten Skin-Screen in eure skin.xml oder skin_user.xml reinnehmen.


    Ohne die Zeile 75 check_Skin(...) müsste es dann wegen "tabbar" zum GS kommen.


  • Ich hab zu der Lösung mal einen erweiterten Feature Request für eine neue Funktion self.getSkinScreenVersion() gemacht.
    Das ganze funktioniert jetzt schon mit dem dort vorhandenen Code.
    Damit kann ein GS wegen eines veralteten, inkompatiblen User-SkinScreen verhindert werden.


    Es wäre nur schöner, wenn DMM diese neue Funktion und das "version"-Attribute allgemeingültig in ihren Quellcode aufnimmt. :winking_face:

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Einfach den Namen des screens andern (Screen_V2), dann wird der skin vom Plugin geladen und der Skinner muss nur die Änderung anpassen + screen Namen, alles gut nach update!

  • Ja, das wäre die einfachste Variante. :winking_face:


    Ich dachte nur, dass es "schöner" ist, wenn man den Skin-Srceen-Namen nicht ändert :winking_face:


    Gibt es irgendwo Festlegungen (Code-Style-Guide) wie man mit solchen Problemen umgehen sollte?


    Ist das offiziell zulässig den Screen-Namen durch Ergänzen mit z.B. "_V2" zu ändern?
    Wäre das auch im Sinne von DMM?

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Der Name ist unerheblich, er muss nur eindeutig sein und am besten keine Sonderzeichen enthalten!
    Ich mach das immer so, weil ein update niemals in einem crash enden sollte. Wenn der skin erst Wochen später angepasst wird stört das um Längen weniger, als wenn ein Plugin in der Zeit nicht benutzt werden kann!

  • Das war auch mein Ziel. Der User sollte nach einem Plugin-Update keinen GS bekommen :winking_face:


    In meiner Skin-Datei (DMConcinnity-HD mit 183 Screens) ist mir allerdings nicht ein einziger "krummer" Screen-Name aufgefallen.
    Daher war ich der Meinung, dass eine solche Lösung nicht zulässig bzw. nicht gewünscht ist.


    Aus diesem Gedanken heraus entstand dann die Idee mit der Versionsnummer im Screen-Tag. :winking_face:


    Aber wenn das Ändern des Screen-Namens kein Problem darstellt, dann ist das natürlich die einfachste Lösung.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • @Sven H die Plugins imdb oder Netatmo haben sowas zb. da wurden ja so einige Sachen für Skins geändert und die Screens und Funktionen weiter ausgebaut ,da hat man dann die Screennamen im Plugin umbenannt und alles ist gut .
    bei imdb zb.name="IMDBv2" bei Netatmo hat man das sogar schon mehrfach gemacht und ist dann jetzt bei name="NetatmoBar_V5"


    Somit knallt da nix,im Plugin gibt es neues und das schlimmste was passiert die User sehen den default skin des Plugins und haben im Skin einen überflüssigen screen drin der dann mal ausgemisstet oder erneuert werden kann.



    Deine Variante ist zwar auch nicht schlecht ,am einfachsten geht es wenn man dem Screennamen verändert so das nix knallen kann.
    Bei einem widget was sich mal ändert muss man das nicht umbedingt machen das kann man einfach mit dazu nehmen wenn man möchte und das fehlt dann bei den alten screens in externen skins aber wenn sich mehr ändert ist das mit dem Screennamen denke das schnellste und einfachste so das die User keinen grünen bekommen.

  • Danke für die Info.
    Dann ist das ja gar nicht so tragisch mit der Namensänderung :winking_face:


    Die von dir genannten Plugins habe ich nicht installiert.
    Sonst wär mir das vielleicht auch aufgefallen und ich hätte mir nicht so viel Gedanken gemacht :winking_face:

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP