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

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

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

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.

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

Ja, das wäre die einfachste Variante.

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

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?

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.

Hallo

Wer kennt das nicht ?
Es gab ein Plugin-Update und dann kommt beim Öffnen des Plugins ständig ein GS weil der User-Skin plötzlich nicht mehr kompatibel ist.

Ich hätte da einen Vorschlag, wie man sowas zukünftig relativ einfach verhindern könnte.
Also keinen GS mehr nach einem Plugin-Update wegen eines veralteten, inkompatiblen User-Skin

In Ergänzung dieser Lösung für den PluginHider hab ich da folgenden aus meiner Sicht recht einfachen Vorschlag.

DMM müsste nur ein neues screen-Attribue "version" offiziell mit aufnehmen.
<screen name="..ScreenName.." version="3" position="center,120" size="820,520" ...>
(bisher erscheint im log noch "WARNING!!!!: unsupported skin attribute version=3")

Dann müsste es eine neue Standard-Funktion self.getSkinScreenVersion() geben (siehe unten), die die Version des zur Anwendung kommenden Skin-Screens ermittelt.
Hat man als Programmierer nun eine Skin-relevante Änderung am Code vorgenommen, die nicht mehr mit dem bisherigen Skin kompatibel ist, muss man nur die Screen-Version im internen Plugin-SkinScreen erhöhen und dann in __init__() mit der Funktion self.getSkinScreenVersion() noch gegenprüfen.

Stimmt die zurückgelieferte Version nicht mit der neuen Versions-Vorgabe im Plugin überein, wird der Plugin-interne Skin-Screen verwendet und nicht der veraltete, inkompatible User-SkinScreen.
Somit könnte man problemlos einen GS wegen eines veralteten, inkompatiblen SkinScreens verhindern

Der User kann das aktualisierte Plugin somit weiterhin nutzen und der Skinner hat Zeit zum Nachziehen des Skinupdates.

Das ganze funktioniert jetzt schon mit dem nachfolgenden Code.
Es wäre nur schöner, wenn DMM diese neue Funktionalität allgemeingültig in ihren Quellcode aufnimmt.

class Plugin...Name...(Screen):


	skin = """<screen name="Plugin...Name..." version="3" position="center,170" size="1200,820" title="Plugin...Title...">
			<ePixmap ...
			...
		</screen>"""


	def __init__(self, session):
		Screen.__init__(self, session)


		skin_version = self.getSkinScreenVersion()
		if skin_version != "3":
			self.skinName = self.skinName + "_load_own_from_Plugin"
		...
		...

Function self.getSkinScreenVersion():

def getSkinScreenVersion(self):
		from skin import lookupScreen
		try:
			myscreen, path = lookupScreen(self.skinName, getDesktop(0).getStyleID())
			skinScreen_version = None
			if myscreen is not None:
				print "=== userscreen found for:", self.skinName
				for item in myscreen.items():
					print "=== item:", item[0], item[1]
					if item[0].lower() =="version":
						skinScreen_version = item[1]
						break
			return skinScreen_version
		except:
			import traceback
			traceback.print_exc()

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

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.

<screen name="PluginHiderSetup" title="PluginHider Setup" position="center,120" size="820,520">
		<ePixmap pixmap="skin_default/buttons/red.png" position="10,5" size="200,40" alphatest="on" />
		<ePixmap pixmap="skin_default/buttons/green.png" position="210,5" size="200,40" alphatest="on" />
		<ePixmap pixmap="skin_default/buttons/blue.png" position="610,5" size="200,40" alphatest="on" />
		<widget source="key_red" render="Label" position="10,5" size="200,40" zPosition="1" font="Regular;20" halign="center" valign="center" backgroundColor="#9f1313" transparent="1" shadowColor="black" shadowOffset="-2,-2" />
		<widget source="key_green" render="Label" position="210,5" size="200,40" zPosition="1" font="Regular;20" halign="center" valign="center" backgroundColor="#1f771f" transparent="1" shadowColor="black" shadowOffset="-2,-2" />
		<widget source="key_blue" render="Label" position="610,5" size="200,40" zPosition="1" font="Regular;20" halign="center" valign="center" backgroundColor="#18188b" transparent="1" shadowColor="black" shadowOffset="-2,-2" />
		<widget name="list" position="10,93" size="800,420" enableWrapAround="1" scrollbarMode="showOnDemand" />
		<widget position="0,50" zPosition="1" size="950,35" name="tabbar" pixmaps="skin_default/epg_now.png,skin_default/epg_next.png,skin_default/epg_more.png" />
		<widget source="plugins" render="Label" position="31,55" zPosition="2" size="200,25" font="Regular;20" halign="center" valign="center" backgroundColor="background" transparent="1" />
		<widget source="extensions" render="Label" position="231,55" zPosition="2" size="200,25" font="Regular;20" halign="center" valign="center" backgroundColor="background" transparent="1" />
		<widget source="eventinfo" render="Label" position="431,55" zPosition="2" size="200,25" font="Regular;20" halign="center" valign="center" backgroundColor="background" transparent="1" />
	</screen>

Ich glaub, ich hab die Lösung

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

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

def check_Skin(self, widgetTag, widgetName):
	from skin import lookupScreen
	try:
		myscreen, path = lookupScreen(self.skinName, getDesktop(0).getStyleID())
		if myscreen is not None:
			print "=== userscreen found for:", self.skinName
			for widget in myscreen.getchildren():
				get_attr = widget.attrib.get
				#print "===", get_attr('name'), widget.tag
				if widget.tag == widgetTag and get_attr('name') == widgetName:
					print "=== old Skin with " + widgetTag + " '" + widgetName + "' found in userscreen:", self.skinName
					self.skinName = self.skinName + "_load_own_from_Plugin"
					print "=== self.skinName change to:", self.skinName
					break
	except:
		import traceback
		traceback.print_exc()

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

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
Stecken die evtl. irgendwo in self (Setup Screen) mit drin ?

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.

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.

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
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.

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

Danke

Hier nun die aktuelle Version inkl. Help-Grafik.
Damit es bei alten Skins keinen Crash gibt, hab ich wie gesagt den Screen-Namen auf "PluhinHiderSetup_New" geändert.

Ich warte noch etwas ab und wenn es keine Probleme mehr gibt, dann kann ich ja den PullRequest machen.

Gerne.

Wenn du den schon fertig hast, kannst du mir den Code schicken oder hier reinsetzen?

Danke

Stimmt auch wieder.
Dann lass ich das erstmal so mit dem geänderten Screen-Namen.

Werde heute Abend nur nochmal eine Version mit dem Wert 170 bei der FHD-Screen-Positionierung hochladen.

Wenn dann alles passt, kann ich ja den PullRequest machen.

Ok, man könnte natürlich alle alten Felder im Code als pseudo-Felder drin lassen und die neuen zusätzlich mit neuen Namen reinnehmen.

Das probiere ich heute Abend nochmal

Ob das dann "saubere" Programmierung ist, weiß ich nicht

Naja, das hab ich ja nicht geschafft.
Die alten Felder waren als StaticText im Code und als render="Label" + source="name" im Screen drin.

Damit hab ich es aber nicht geschafft, die Farben über den Plugin-Code nachträglich zu ändern.

Zitat von dhwz

OK mehr wollt ich ned wissen. Ja das ist immer doof so eine Änderung. Entweder es Crasht oder das Skin passt nicht mehr. Aber GS wollen wir alle nicht

Hab gerade gesehen, dass zombi in seinem Screen die tabbar-Felder (plugins, extensions..) nicht mit drin hat.
Daher werden die dann aus dem Plugin-Code-Screen geholt.

Wenn man im eigenen Skin im PluginHiderSetup-Screen aber die alten Felder mit drin hat, knallt es

Zitat von zombi

...
der FHD screen noch nicht ganz positioniert ist ,passend zu der vorhandenen Standardgröße.
So hatte ich das in den Default-FHD Skin eingebaut
<screen name="PluginHiderSetup" position="center,170" size="1200,820" title="PluginHider Setup">

Stimmt, die 170 hab ich nicht. Bei mir steht da "center".
Dann ändere ich das noch.

Wie siehst du das mit der Änderung des Screen-Namens?
Wenn ich den nicht ändere, kann es mit alten Screens zum GS kommen.
Im Moment ist im Code ein neuer Screen-Name drin. so dass es keinen GS gibt.

Zitat von dhwz

Ich sagte doch ich hab das in tabbar (seletedlistColors) umbenannt
Nein das war der Screen von zombis Skin ich bin ned bescheuert

Klar crasht was wenn du einen völlig anderen Widgetnamen verwendest den kein Skin kennt.

Jetzt hab ich es geschnallt
im FullHDR3 knallt es damit tatsächlich nicht.

Mit dem alten Screen in meinem Skin knallt es aber.

Nun ist die Frage, wie man damit umgeht???
Es knallen lassen und warten bis die Skins angepasst sind oder den User schützen und einen neuen Screen-Namen verwenden und die Skinner müssen dann nachziehen.

Also bei mir kommt dann mit FullHDR3 ein GS wegen "tabbar".

Da scheint die Änderung bei dir nicht gegriffen zu haben.
Eigentlich sind es ja sogar 3 Stellen zum Ändern, wobei die 3. Stelle dann ja nur den HD-Screen betrifft.

Es gibt ja auch definitiv das neue MultiColorLabel " seletedlistColors", was zombi ja auch noch nicht drin hat.

Da wird bei dir irgendwie noch der Plugin-interne Screen verwendet.