Skindesigner 0.8.8

    Tag zusammen...
    soo ich habe jetzt auch endlich mal ein wenig Zeit meinen Skin an den neuen SkinDesigner anzupassen,
    ist zum Glück nicht viel.. die erste Version des tryouts-Skins war schon fertig, als es die "detached" Attribute noch nicht gab ;)
    Aber scrollelemente natürlich, und dazu habe ich auch eine kurze Frage:

    Zitat

    "name" für scrollelement in <areascroll> darf nicht für mehrere Funktionen definiert sein, sondern nur für die Funktion, für die "current" "true" ist.


    Das verstehe ich nämlich nicht ganz, kann ich denn sowas machen?


    Code
    <area x="1%" width="32%" layer="2">
		<drawimage condition="{current}" name="menuitemback" imagetype="skinpart" path="menuitemback" x="0" y="2" width="{areawidth}-2" height="{areaheight}-4"/>
		<drawellipse condition="eq({nummenuitem},0)" x="{areawidth} - {areaheight}*0.80" y="0" width="{areaheight}*0.80" height="{areaheight}*0.80" color="{clrTransparent}" quadrant="-1"/>
	</area>


<areascroll scrollelement="menutext" mode="forthandback" orientation="horizontal" delay="1000" scrollspeed="medium" x="2%" width="30%"  layer="3">
		<drawtext name="menutext" x="0" valign="center" font="{vdrOsd}" fontsize="75%" color="{clrWhite}" text="{number} {label}" />
</areascroll>


    //edit:
    und kann es vllt sein, das sowas nicht mehr funktioniert?

    Code
    <menuitems condition="eq({useLongRecList},1)" x="0" y="45%" orientation="vertical" width="100%" height="55%" align="center" numlistelements="11">

    ?


    [size=10]nOpacity: Icons
    [size=10]skindesigner: tryoutsglassy

    Einmal editiert, zuletzt von BooStar ()

    Hi...
    jaa.. da stimmt was nicht .... bei

    Code
    <menuitems condition="eq({useLongRecListX},1)"...


    knallts... useLongRecListX zwar nicht definiert, aber trotzdem...


    Code
    Feb 27 20:03:27 yavdr01 vdr: [1947] skindesigner: trying to load: /var/lib/vdr/plugins/skindesigner/installerskins/tryouts/themes/red/icons/ico_timer_recording.png
Feb 27 20:03:27 yavdr01 vdr: [1947] skindesigner: trying to load: /var/lib/vdr/plugins/skindesigner/installerskins/tryouts/themes/red/skinparts/line_bottom.svg
Feb 27 20:03:27 yavdr01 kernel: [  301.387659] vdr[1947]: segfault at b0 ip 00007fd3f62f4fe2 sp 00007ffefab8dbb0 error 4 in libvdr-skindesigner.so.2.2.0[7fd3f6256000+13c000]
Feb 27 20:03:27 yavdr01 kernel: [  301.417246] init: vdr main process (1947) killed by SEGV signal


    /edit:
    ein backtrace ist im anhang

    Dateien

    crashlog.20160227201940.txt 36,92 kB – 252 Downloads


    [size=10]nOpacity: Icons
    [size=10]skindesigner: tryoutsglassy

    Einmal editiert, zuletzt von BooStar ()

    Hallo,


    Zitat von BooStar

    useLongRecListX zwar nicht definiert


    nicht vorhandene Setup-Parameter in conditions bzw nicht gesetzte Tokens generell schluckt der neue Skindesigner nicht mehr. Das Lehrgeld durfte ich auch schon zahlen ;)


    louis zum Thema nicht gesetzte Tokens: metrixhd ist mir beim Testen gerade in der Kanalliste ausgestiegen, als ich auf einen Kanal ohne EPG gekommen bin, weil die Tokens im currentelement in diesem Fall ja alle nicht gesetzt waren.


    Gruß,
    Tomas

    Moin,


    jo der neue Skindesigner ist da weniger tolerant als die alte Version. Ich habe da aus performancegründen einiges an Hosenträgern weggelassen. Da müssen die Skins eben sauber sein ;)


    Zitat von tomas

    louis zum Thema nicht gesetzte Tokens: metrixhd ist mir beim Testen gerade in der Kanalliste ausgestiegen, als ich auf einen Kanal ohne EPG gekommen bin, weil die Tokens im currentelement in diesem Fall ja alle nicht gesetzt waren.


    Das soll natürlich nicht sein. Hast du mal nen Coredump?


    Ciao Louis

    Moin Louis,


    ich dachte, die Ursache wäre bei fehlendem EPG für den betreffenden Kanal klar: nicht gesetzter presenteventitle etc im currentelement. Wenn man das im Skin mit 'isset' abfängt, ist alles gut.



    Gruß,
    Tomas

    Hm, eben nochmal getestet, bei mir crasht da nichts. Es wird halt einfach nichts angezeigt...so wie das eigentlich auch sein sollte. Tokens können ja immer leer sein, das kommt ja dauernd vor. Mit "isset" im Skin abfangen darf nicht nötog sein, das wäre ja viel zu aufwändig.


    Irgendwas ist da bei dir anders...ich habe das eben auch nochmal ohne das epg2vdr Plugin getestet...crasht aber immer nochnix.


    Ciao Louis

    OK, danke für die Info...


    aber

    Code
    <menuitems condition="eq({useLongRecList},1)"...


    zieht trotzdem nicht. ...
    Ich kann mir in dem Fall auch nicht mit <areacontainer> helfen, da ich unterschiedliche "numlistelements" brauche...


    [size=10]nOpacity: Icons
    [size=10]skindesigner: tryoutsglassy

    BooStar: d.h. du hast für verschiedene Conditions jeweils komplett eigene <menuitems> definiert? Hm, das habe ich wohl noch gar nicht implementiert. Ging das beim in der alten Version? Erstaunlich ;)


    Ciao Louis

    Hi Louis,
    ja.. das hat funktioniert..
    Wenn du dieses Feature nicht für sinnvoll hälst, kann ichs auch weglassen, wobei...warte mal ... mir fällt grade ein, man könnte "numlistelements" natürlich auch variable machen,
    dann müsste man in der globals.xml sowas machen können ;)


    Code
    <var condition="eq({useLongRecList},1)" type="int" name="numlistelement">15</var>
<var condition="eq({useLongRecList},0)" type="int" name="numlistelement">8</var>


    Also ohne deine wirds nicht gehen, louis...


    Wir können jetzt gerne drüber diskutieren obs sinnvoll innerhalb eines Skins verschiedene Ansichten anbieten zu können...
    Ich finde schon... ;)


    [size=10]nOpacity: Icons
    [size=10]skindesigner: tryoutsglassy

    H Boostar,


    ich habe da eh noch einen Feature Request offen, der genau in die Richtung geht, die Anzahl der Elemente in einer Liste variabel bzw. konfigurierbar zu machen. Deine Anforderung wird damit dann ja auch erschlagen...


    Ciao Louis

    Hallo Louis,


    Zitat von louis

    bei mir crasht da nichts. Es wird halt einfach nichts angezeigt...so wie das eigentlich auch sein sollte.


    Mit metrixhd und simplex ist das bei mir zu 100% reproduzierbar, mit blackhole und blackholefrodo gibt es hier auch keine Probleme...solange das nur bei mir passiert, muss man das nicht weiter verfolgen.


    Aber mal was ganz anderes: wäre es viel Aufwand, in der displaymenudefault ein Token für die Menükategorie mcTimerEdit zur Verfügung zu stellen?


    Ich habe mich ja die letzte Zeit etwas mit den Menükategorien befasst und bin dabei auch mal wieder über das remotetimersplugin gestolpert. Du hattest da zwar mal einen Patch empfohlen, der die Spalteneinteilung des Menüs zum Editieren der Timer so anpasst, dass auch mit einem Skindesignerskin die zweite Spalte lesbar ist (ursprünglich stehen da ja nur vier Zeichen zur Verfügung), aber das eigentliche Problem ist, dass remotetimers an dieser Stelle keine Menükategorie setzt. Eigentlich sollte hier ja mcTimerEdit gesetzt werden, aber da die in einem Skindesignerskin momentan noch nicht berücksichtigt werden kann, macht das ja keinen Sinn.


    Ich habe jetzt mal testweise das hier gemacht:


    Code
    cMenuEditRemoteTimer::cMenuEditRemoteTimer(cTimer *Timer, bool Remote, bool New, cMenuTimerItem **TimerItem)
:cMenuEditTimer(Timer, New), timer(Timer), timerItem(TimerItem)
{
++  SetMenuCategory(mcPluginSetup);
++  //SetMenuCategory(mcTimerEdit);
  SetCols(15, 4, 12);



    Damit zieht in der displaymenudefault die condition mit {setup} und im metrixhd, simplex und meinen Skins, die die zweispaltige Ansicht des Setups mit erste Spalte linksbündig, zweite Spalte rechtsbündig vorgesehen haben, sieht das passend zu den anderen Menüs mit Einstellungen aus s.u..

    Eigentlich ist mcPluginSetup an dieser Stelle ja aber nur eine 'Notlösung', mit einem eigenen Token wie 'timeredit' oder... wäre man natürlich flexibler.

    Im vdr selbst wird für dieses Menü übrigens auch mcTimerEdit gesetzt:

    Code
    cMenuEditTimer::cMenuEditTimer(cTimer *Timer, bool New)
:cOsdMenu(tr("Edit timer"), 12)
{
  SetMenuCategory(mcTimerEdit);



    Ein entsprechendes Token wäre also auch zukunftsträchtig, wenn man bedenkt, dass mit vdr-2.3.1 remotetimers eigentlich obsolet ist. Trotzdem würde ich im Fall mit smirl Kontakt aufnehmen, ob er einen entsprechenden Patch einpflegen würde.


    Gruß,
    Tomas

    Hi Tomas,


    gute Idee...ich würde das aber allgemeiner angehen und für jede Menü Kategorie, die vom Skindesigner nicht gesondert behandelt wird und das Default Menü benutzt wird, ein entsprechenden Token setzen, der genau so heisst wie die Menükategorie. Also z.B. mcTimerEdit, mcRecordingEdit, ...


    Würde das für dich passen? Dann baue ich das gleich mal ein, ich habe gerade Lust und Zeit ;)


    Ciao Louis

    Hallo Louis,


    Zitat von louis

    für jede Menü Kategorie, die vom Skindesigner nicht gesondert behandelt wird und das Default Menü benutzt wird, ein entsprechenden Token setzen, der genau so heisst wie die Menükategorie. Also z.B. mcTimerEdit, mcRecordingEdit, ...

    Gleich alle zu 'fordern', wäre mir ehrlich gesagt zu unverschämt gewesen ;)


    Zitat von louis

    Würde das für dich passen?

    Das fasse ich jetzt mal als rhetorische Frage auf ;) .... skindesigner rulez :]


    Schönen Sontag noch
    Tomas

    Zitat von 9000H

    gibt es einen Plan wann vdr-2.3.1 unterstützt wird.


    demnächst...wenn ich keine neuen Bugs reported bekomme und ich mal wieder Zeit habe ;)


    Ciao Louis

    Moin,


    im Git gibt es eine neue Version 0.8.7 mit den folgenden Fixes:


    Code
    - fixed nextrecording token in displaychannel
- added poster and banner to channels and timers menu current view
- added zaphistory plugin token for default menus
- fixed bug that header was not drawn in menudetailedtext
- added tokens for various menucategories in menudefault
- fixed svdrp error codes


    Ciao Louis

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden