Skin Entwicklung

  • wollte mich mal ein bisschen mit skin-entwicklung beschaeftigen und habe mir den metrix skin "durchgelesen"......
    war etwas geschockt, da ich bisher dachte, ein skin sei eine xml-file, in dem ein paar settings gesetzt werden.
    aber der metrix ist ja ein monster von python code und xml files, die dynamisch zusammengesetzt und modifiziert werden.
    wie bekommt man da einen ueberblick?
    gibt es eine "architektur"-beschreibung irgendwo?
    danke.

  • ja, den metrixstyle hd meinte ich... :smiling_face: ... schoener skin uebrigens...
    denke, das grundgeruest eines skins ist eine xml-file in der mit convertern und renderern service und box spezifische infos angezeigt werden.
    diese converter und renderer laufen asynchron mit einer bestimmen frequenz unabhaengig z.b. von einem plugin vor sich hin.
    wo die daten herkommen wird vermutlich durch die sources irgendwie bestimmt.
    soweit ok?

  • Es gibt Converter die ein poll-Interval drin haben und solche ohne. Ohne wird ein Converter beim Skin-Aufruf einmal druchlaufen und liefert die Info zurück (z.B. DreamboxModel.py). Converter mit poll-Interval updaten sich selber und halten den Screen im Skin aktuell (z.B. BoxInfo.py).


    Und ja, es gibt Monster-Skins mit vielen, vielen Tausend Zeilen Code. ABER, es geht aber auch einfacher. Ich habe für uns Zuhause meinen eigenen Skin mit "nur" 1200 Zeilen Code. In diesem Skin sind nur die wichtigsten Screens für den täglichen Gebrauch drin und ein paar wenige Plugins. Der Rest wird mit den Default-Plugin-Screens dargestellt. Wird auf einen Default-Plugin-Screen zurückgegriffen, wird dieser aber trotzdem mit meinen Default-Farben und meinem Fenster-Grundlayout aus meinem Skin dargestellt.

  • Yes...


    The xml file consists of screens, every screen has its own name and they are defined in python codes. either in plugins or in OS code (also python code). What you can show on screen (osd) is what is programmed in that python code. If you want to show something custom (not defined in python code), you have to program it in the python code or use converters/renderers that can be used with the spesific screen regardless of code. The xml (skin) file is there for you to use custom graphics, placements, font styles and font sizes and more.


    Lets say you want to change something in "Infobar" screen. Search up name="InfoBar" in skin.xml of the skin you want to edit. Everything in between <screen and the next </screen> is what this specific screen will give you on TV screen. You can change whatever you want.


    Converters and renderers are used to pull out desired text from the system. There are many standard converters and renderers and there is plenty 3rd party ones. What you want to show on screen determines what converter and/or renderer you will use.


    When you decide to build skins, it is very nice to understand some python code. This code will tell you what you can show on screen and if there is something new added to a python screen since last time you edited your screen.


    For my example screen "InfoBar" the python code is in /usr/lib/enigma2/python/Screns/InfoBar.py. Take a look and you will find things defined in skin.xml.


    Every name="<screen_name>" in skin.xml refere to one screen on TV. One for main menu, one for Infobar and so on... How many screen you will find in a skin xml is different. It has to do with how serious the skin maker have been. Most python code have screens defined within python code. If skin.xml dont have it defined, the python screen will show on screen. If not defined in your python screen code and in your skin.xml, code will fail with GSOD.


    Yes, to be a skin maker is a monster job. Especially if you want your skin to cover all screens and plugins out there...


    No easy overview of total screens and their names, you have to know your OS code and where to find it on your system.

    - FoxyRabbit - Peter Pan team -

    2 Mal editiert, zuletzt von FoxyRabbit ()

  • Das meiste stimmt auch noch. Error Handling ist immer wichtig. Die Dokumente sind aber schon älter.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • If a renderer or converter is correct programmed the info you pull out will automatically change when there is changes in the system. Lets say you want to get the name of current program, det name will change imediatly when the next program starts.


    If you have some exact examples of what you are trying to do in your skin, it would be better to explain.


    We need "screen name" and the exact line of the "thing" you want to show/change on screen.

    - FoxyRabbit - Peter Pan team -

  • Du sollst Converter nicht aus den Plugin raus manipulieren! Wenn du etwas selbst steuern willst, dann kannst du ein Label nehmen und dieses mit neuen Werten aktualisieren. Sinn und Zweck der Converter ist, dass du dich nicht mehr um die Aktualisierung kümmern musst

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • das ist mir soweit klar... aber label sind in ihrer funktionalitaet sehr eingeschraenkt.
    die frage ist, ob man renderer auch "customizen" kann, also z.b. grösse dynamisch veraendern kann.
    beispiel:
    ich habe 3 widgets:
    label: event name
    label: short event description
    renderer: extended event description
    wenn es keine short event description gibt, dann moechte ich das feld der extended event description groesser machen, sodass der freie platz der short event description mitgenutzt wird.
    gibt es dafuer einen ansatz?

  • Es gibt einen Converter mvepgEventDesc, wo man short und extended desc in ein Feld schreiben lassen kann.


    Dadurch hat man automatisch mehr Platz für die extDesc, wenn es keine shortDesc gibt.


    Da kann man dann aber keine unterschiedliche Formatierung für beide Werte machen.

    Gruß Sven (aka Dreamy)


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

  • es geht um den renderer runningtext, der die beschreibung von unten nach oben scrollt. fuer den wuerde ich gerne die groesse dynamisch anpassen.
    aber das ist vermutlich gar nicht vorgesehen.

  • Ich glaub, ich hab bei mir den runningtext mit dem Converter für short+extDesc kombiniert.
    Hab also für short+extDesc nur ein Feld, was nach oben durchscrollt.


    Falls dich das interessiert könnte ich das Abend mal raussuchen.

    Gruß Sven (aka Dreamy)


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

  • naja, einfach den text kombinieren wuerde ich auch hinbekommen.
    aber falls eine short description existiert, dann soll die ja in dem feld stehen bleiben und nicht mit nach oben scrollen.
    aber eigentlich war die frage, ob man bei renderern die skin attribute wie groesse, position, etc. wie bei convertern dynamisch aendern kann.
    vielleicht kann @Reichi da mal ein kurzes statement absondern, ob das ueberhaupt vorgesehen ist.

  • Also eigentlich ist es ganz einfach: es geht was Du willst, Du musst das nur selber implementieren. :winking_face:


    Es ist ganz einfach: Du erstellst Dir Deinen eigenen Renderer, welchen Du eine Position und eine Größe im Skin zuordnest. Diese Angaben solltest Du als Maximal-Werte verstehen, diese sind nicht dynamisch.
    Innerhalb dieses Widgets zeichnest Du, bezogen auf die Pos/Size, an die entsprechenden Stellen Deine Sachen, dort wo Du nichts zeichnest setzt Du beispielsweise einen transparenten Hintergrund. Und fertig wäre die "dynamische" Größe. Wohin Du innerhalb dieses Widgets malen willst musst Du natürlich dynamisch errechnen, auch das geht mit Enigma2 Befehlen, wenn Du beispielsweise Text ausgeben willst, denn Du kannst errechnen lassen, wie viel Pixel ein Text in Höhe/Breite einnimmt.


    Happy Coding! :smiling_face: