XLMTV EPG Importer (Rytec EPG) for DreamOS

  • Also gut, nachdem zombi sich über den erbärmlichen Skin im EPGImport Plugin beklagt hat (und ja die Version auf der ersten Seite ist bewusst derzeit aus dem Original vom Feed unserer Holländischen Freunde geholt und dann ans DreamOS angepasst) was hätten wir für Möglichkeiten:


    Wir können beispielsweise die Version von den VUnderboxen borgen, weil die Mädels haben das wenigstens auf HD/FHD umgehämmert ?


    Wenn ich das machen würde, dann müsstet Ihr als Skinner mir aber sagen ob das als Basis brauchbarer ist, weil nur wenn es was bringt würde ich das als Basis für eine neue DreamOS Version nehmen.


    Sprich ich könnte mal eine Version machen die im DreamOS startet und bedienbar ist, aber eben noch nicht funktioniert, weil zum Skinnen wäre das erstmal egal.


    Wenn uns das Ergebnis gefällt mache ich dann auch den Rest ...


    Wie gefällt Euch der Vorschlag :evil:


    Ich habs ausprobiert, sieht genauso Sch* aus - aber jetzt weis ich woran es liegt ... Geduld ...

  • OK auf der ersten Seite ist jetzt eine r201 wo wenigstens ein Basic FHD Support drinnen ist und auch die Hardcoded Parameter mit sz_w für FHD wenigstens Verdoppelt werden.


    Theoretisch müsstet Ihr damit jetzt in der Lage sein die Default skins des Plugins an den Standard Skin vom DreamOS in den *.py anzupassen.


    Wenn das jemand macht (nur in der plugin.py der filter*.py und der Expandable*.py nach sz_w suchen für die nötigen Stellen) mache ich daraus dann einen neuen kit und der sollte dann auch wenigstens so halbwegs skinnbar sein.


    WENN ihr die *.py entsprechend zuende anpasst dann sehen wir mal weiter ... weil ich mag nicht immer alles alleine machen. Und wenn nicht ... dann bleibt es halt erstmals so wie es ist ...:P

  • Ich schau mir das heute abend mal an und würde dir das Plugin dann richtig mit HD und fhd default screens erstellen. Im DreamOS ist das auch viel besser lösbar als da das mit sz_w zu verdoppeln, schon auf Hinsicht weiterer Skin Auflösungen die dann auch automatisch richtig gehen😉

    Mir wäre zwar ein einfaches Import für dein Export lieber aber ok wir können auch das hier dann mal anständig anpassen und nicht so experimente machen wie bei den open... 😉

  • Danke, das verdoppelt war nur Q&D um zu sehen ob es funktioniert.


    Ich kann dir wenn es sein muss auch die komische Routine aus den Open* Images nachbauen, welche die skinparameter ausliest, um sie dann nicht hardcoded zu machen, aber ich denke in diesem Fall sollte es auch ohne gehen, wenigstens für den Standard Skin in HD und FHD.


    Ich habe beim Portieren aufs DreamOS diese Routinen ja nur auskommentiert und durch die Default Werte ersetzt, womit nur eine Auflösung funktioniert hat, jetzt gibt es dort auch wenigstens eine Werte Liste params für zwei Auflösungen, womit das bereits besser funktionieren sollte.


    Viel Erfolg


    PS: wenn es uns zu blöde wird kann ich immer noch was eigenes machen, aber man soll auch nicht zu früh aufgeben.

  • Brauchst du nicht ich kenne die vom DreamOS sehr genau und damit geht das besser als bei den open, das brauchen wir hier nicht 😉 Reichi hat uns da was gutes ins DreamOS gebaut womit wir da mit viel weniger, viel mehr und automatisiert erreichen können, lass mich das einfach mal heute abend nach der Arbeit ansehen und werkeln, denke das wird schon klappen. 🙂

  • Sieht dort im Code recht wüst aus muss mal sehen, Zeilenhöhe, font, Abstand usw. kann man gut im DreamOS mit den listen fonts und den component regeln im Code (DAFÜR IST DAS Gedacht), somit passen sich die fonts sowie auch die Positionen alles je nach skin an was der skinner da dann angiebt.

    Deshalb gibt es ja auch den default fhd da hab ich das dann alles default auch eingebaut so das fhd automatisiert zu den default screens passt.

    Das ganze geht dann auch mit anderen Skin Auflösungen ohne das man dann das Plugin nochmal anfassen muss.

    Mit weniger Einträgen erzielht man hier mehr Flexibilität und das dann auch automatisiert durch die skin Einträge.

    Ohne das im Plugin vorgegeben werden muss für welche Skin Auflösungen das dann verdoppelt oder... wird.

    Wie gesagt bei solchen fremdplugins ist das immer so eine Sache die dann umzuhämmern wenn da die open Jungs ihr zeugs reingemacht haben was im DreamOS so halt nicht nötig wäre.

    Ich mag das nicht so gern, da lieber ein neues was auch anständig ans DreamOS angepasst ist und nicht sinlosses mit sich schleppt nur damit es bei den open... auch läuft.

    Setze halt er auf DreamOS als auf die anderen, kann jeder ja machen wie er lustig ist.

  • Das Logo ist meine geringste Sorge.


    Eigentlich ist der ganze Blödsinn primär wegen dem Expandable*.Python wo man die XML Quellen aufklappen und selektieren kann. An allen anderen Stellen ist das leicht anpassbar. Theoretisch könnte man das neu schreiben und auf eine simple Liste umschreiben so wie im EPGExporter, aber wie schon gesagt probieren wir es erstmal so wie es ist.

  • Genau das meinte ich mit neu machen als einfaches Plugin als so wie es jetzt ist mit dem ganzen altbacken zeugs was heute garnicht mehr benötigt wird.

    Das ganze umhämmern von alten zeugs was die open oder v... oder... alle noch nutzen macht nicht wirklich immer Sinn, wir können das im DreamOS eleganter und auch mit besserem Code machen da muss man nicht mehr auf das alte schauen.

    Ich verstehe zwar das viele halt auch andere Boxen haben und dann auf Sachen nicht verzichten möchten, nur wenn wir da nicht weiter gehen und auch auf neues setzen dann brauch man sich nicht wundern wenn es Abgänger gibt, denn ehrlich auch wenn die anderen da auf altem e2 bauen das sie verändern können so machen sie das und patchen es zwar zu Tode und nicht immer ist da alles schön, aber sie machen was das andere nicht machen (Siehe vmc, globale suche, horizontale Listen mit Kachel Ansicht wie viele neu Medien Ansichten heute aufgebaut sind usw.)

    Alles das geht dort mit altem oe, auch wenn es nicht immer gut geht aber es geht und sowas zieht User an und das haben wir hier leider verpennt oder ignorieren es.

  • gutemine ist doch immer für was total neues zu begeistern, von daher .... ;)


    ... ansonsten hinken wir den anderen immer nur hinterher, und kommen in den Ruf, alles nur nachzumachen, weil uns eigene innovative Ideen fehlen. Ob die jetzt gewissenlos auf Lizenzen pfeifen, sei mal hinten angestellt.

  • Na ja das Plugin ist auch ein Spezialfall, das wurde ursprünglich ohne GUI geschrieben, deswegen ist in der EPGImport immer noch ein Main um es als Python Script ohne GUI aufzurufen, und der Teil ist steinalt und selbst simple Sachen wie ob ein File existiert werden mit Try/except gemacht, womit selbst mir schlecht wird und ich bin nicht gerade für sauberen Code bekannt, sprich ich akzeptiere schon eine Menge wenn es funktioniert. Da hat dann scheinbar wer anderer eine GUI dazu gemacht und seitdem wird dran nur rumgebastelt.


    Theoretisch kann man das schon auch alles neu schreiben oder den Code gnadenlos aufräumen aber ich habe selbst genug Müll den ich mitschleppe, warum soll ich weiteren von der Straße auflesen. Mir ist schon klar das du auch Bauchweh hast das anzupassen, aber wenn wir immer nur jammern wird es nie besser. Probier dein bestes, zur Not nimm halt weiterhin die hardcoded Werte so daß es wenigstens für den Standard Skin passt und dann können wir uns immer noch überlegen ob der Rest die Arbeit wert ist. Weil mehr als ein paar Stunden Arbeit ist mir das auch nicht wert.

  • Nicht umsonst bin ich so erpicht drauf und versuche Reichi und einige andere Programmierer auch für was neues zu begeistern, nicht von allen kommt da immer Begeisterung aber einige haben da schon ein offenes Ohr. 😉 Und Reichi ist da echt ne coole Socke 🙂, er macht und hat da echt viel mitgemacht und hat auch oftmals selbst nen kleinen anschupser gegeben. 👍

    Ich lerne dann auch einiges dabei und kann in gewissem Maße auch helfen, programmieren ist da aber nicht mein Ding.

    Ich schau mir das Teil heute Abend wie gesagt mal an und versuche da mal default was, für meinen fhd flat hatte ich es ja am we. geskinnt da passte nur eine einzige Liste nicht den Rest konnte man schon rein im skin lösen ohne das Plugin anzufassen.

  • Dann mache bitte alles bis auf diese Liste für den Standard Skin, zur Not spiele ich mich dann nachher auch noch mit den Parametern für diese Liste bis es okay aussieht und dann sehen wir eh ob es auch für andere skins geht. Der Standard Skin ist wegen dem overscan ja relativ klein aber dann kann die Liste in anderen skins auch maximal etwas zu klein aussehen, womit die Skinner und User aber leben können sollten. Im Moment würde ja eine HD Liste in einem FHD Skin angezeigt und das sollte schon mit der r201 gefixed sein.

  • So hab mal alles soweit angepasst (rein nur mit default Skin Einträgen ohne extras ) sind dann deine Sachen mit sz_w drin für die Umschaltung bei HD und FHD .

    Das hier sind dann mal die default FHD screens ,analog dann die default HD screens,alles passend zu den beiden System default Skins des DreamOS.

    Die eine Datei wo dann der Inhalt der Sourcesliste angegeben wird muss ich mal schauen ob ich mir da die Arbeit mache eine componente zu bauen oder dann einfach nochmal über deins gehe mit den Angaben für HD und FHD als feste Angaben .

    Reicht denke aus bei dem Plugin da muss man sich nicht die Arbeit machen das es dann auch noch in anderen Auflösungen geht weil dazu lohnt es sich einfach nicht mit dem Teil.


  • Danke, hast du schön gemacht und wie schon gesagt, dann bleibt nur mehr die ExpandableSelection.py über, da sind 3x Koordinaten mit sz_w verzeigt und einmal ein Font, wobei ich nicht sicher bin ob man den nicht auch skinnen können sollte.


    Wenn du daran scheiterst kann ich mich schon spielen dafür brauchbare Werte zu finden das alles in die Screens des Default Skins passt, aber probier es erstmals selbst. Im Cosde stehen eh immer die skin objekte drüber auskommentiert wo er sich mit dem Namen die Werte aus dem skin holt, insofern ist das nicht so schwer zu verstehen was da reingehört selbst wenn man es mal hardcoded.


    Neuschreiben kann ich das Teil dann immer noch wenn wir scheitern :P Mit einer ConfigNone für die FeedNamen und ConfigYes/No für die einzelnen EPGExport würde das dann problemlos skinbar sein8)

  • Die haben da ihr Zeug rein gemacht und mit 0,1,2 benannt und dann überall da was angegeben ,normal geht das im DreamOS mit

    from skin import TemplatedListFonts


    und


    Code
    1. tlf = TemplatedListFonts()
    2. self.l.setFont(0, gFont(tlf.face(tlf.MEDIUM), tlf.size(tlf.BIGGER)))


    Und dann werden die Fonts aus der Skin Kopfzeile oder default skins genommen ,das ist dann Skinbar und nicht mehr fest.

    Auch die itemHeight kann angegeben werden und wie gesagt für den Inhalt dann auch componente gesetzt ,nur ich will da wirklich nicht im code rumwerkeln wo ich nichtmal das Import teil wirklich nutze ,da mache ich nachher noch mehr kaputt weil ich garnicht weiß für was die da alles Angaben drin haben.


    Code
    1. self.l.setItemHeight(componentSizes.itemHeight(self.SKIN_COMPONENT_KEY, 25))
  • Na gut wenn du mir die plugin.py postest, dann mache ich halt sinnvolle fixe Werte rein und dann schauen wir ob das gut aussieht ^^


    Besser als jetzt ist es auf jeden fall und der Aufwand hält sich noch in Grenzen.


    Die Skinner sind dann halt immer noch ein bisschen eingeschränkt, aber man kann halt nicht alles haben.

  • Ich mach mal einen kit draus, dann testen sozusagen alle :P


    EDIT: die 1.0-r202 ist jetzt auf der ersten Seite mit deinem neuen Skins in HD und FHD sowie dem neuen Logo.


    Ich denke fürs erste reicht es mal so und danke für Eure Mühen.


    Wenn sich jetzt arki mit einem Metrix Style dran versuchen will sehen wir dann ja ob es was gebracht hat :love:

    Aber jetzt sieht es auch ungeskinned wenigstens nicht mehr so seltsam aus:thumbup:

  • Hallo.

    Kann man damit wieder "gz" Format ziehen oder nur noch "xz" ??



    Ist leider so das man es immernoch braucht, sonst müsste die halbe Welt noch lange bei 36.6 bleiben.