$PARAM[focused] --> geht nicht in einer fixedliste?!

  • Hallo,


    ich habe nen problem an dem ich schon länger fuckel aber es will einfach nicht, vielleicht weiss da einer der anderen skinner was, und zwar folgendes.


    Ich habe nen container, eine fixedlist, in der ich mir dem itemlayout content und focusedlayout content includiere.

    Das includierte ist gleich, ob itemylayout oder focusedlayout mit einer unterscheidung ich setzte beim includieren folgendes in den itemlayout :

    Code
    <include content="InfoWallMovieLayout_vertical">
    <param name="focused" value="false" />
    </include>


    und für den focusedlayout natürlich auf TRUE

    Code
    <include content="InfoWallMovieLayout_vertical">
    <param name="focused" value="True" />
    </include>


    soo, nun habe ich im includierten content folgendes image was mir nur beim focus angezeigt werden soll.

    Code
    <control type="image">
    ............
    <texture colordiffuse="$VAR[color_choose_listfocus_scrollbar]">colors/grey.png</texture>
    <bordertexture border="21">overlays/shadow.png</bordertexture>
    <visible>$PARAM[focused]</visible>
    <include condition="$PARAM[focused]">Animation_FocusTextureFade</include>
    .......
    </control>

    das problem ist aber er nimmt das nicht an, er zeigt mir immer das image an, auch wenn der container nicht makiert ist.....
    makiere ich den container dann einmal und gehe wieder zurück dann geht es dann blendet er mir das image aus.... :?:

    desweiteren ein komisches verhalten, ändere ich den container von einer fixedlist auf ein panel macht er genau das was er soll, ohne ein problem.....

    hat da jemand ne idee?

  • Ich muss gestehen, dass ich mich mit params noch nicht so befasst habe. Aber gelten die nicht global? Kann denn ein param dann gleichzeitig "true" (für das focused Item in der Liste) und "false" (für die unfocused Items) sein?

    Wäre es nicht besser, das Image-Control nur in das focusedlayout reinzustecken?

    Nur ein spontaner Gedanke ohne es selber getestet zu haben …

  • Ich muss gestehen, dass ich mich mit params noch nicht so befasst habe. Aber gelten die nicht global? Kann denn ein param dann gleichzeitig "true" (für das focused Item in der Liste) und "false" (für die unfocused Items) sein?

    Es gibt ja leider nicht viel Erklärungen zu irgendwas.

    Ich hab es mir so Erklärt aus den wenigen Parametern die ich verwendet hab bisher das die im Prinzip immer nur beim laden quasi als Klartext eingetragen werden was drin steht.

    <left>$PARAM[Left]</left> und Left=120

    führt dann halt zu <left>120</left>

    Und gilt auch nur für diesen einen includeaufruf und sonst nirgends, außer man gibt in der include definition einen defaultwert an. Dann gilt der wenn nichts angegeben wird
    pro includeaufruf.

    Deswegen find ich die Dinger teils recht sinnlos weils schnell nur ne andere Schreibweise ist.
    Was spar ich groß wenn ich nen Dialoghintergrund mit vier Werten im include Aufruf positionier. Ist auch nur ne andere Schreibweise als gleich <left>120</left>

    Wenn was globales haben willst wären eher constants das richtige, ist zwar auch nur ne andere schreibweise, aber dadurch kann man werte staffeln und auch global ändern und es stimmt
    überall.

    Grüße

  • ja sicher, nur sind focused layout und itemlayout der sselbe content.

    Deswegen das param.

    Ja, und genau das verwirrt mich eben. In itemlayout und focusedlayout wird eigentlich nur das Styling für den Inhalt des Container definiert. Der eigentliche Content kommt dann normalerweise zwischen die <content> … </content> Tags. Es heißt ja nicht umsonst itemlayout und focusedlayout.

    @Marc0810
    Da geht es mir wie dir. So ganz bin ich noch nicht hinter die Sinnhaftigkeit der params gestiegen. Die wirken auf mich irgendwie umständlich und machen den Code für mich nur schwerer lesbar. Aber ich bin auch nur ein Gestalter und kein Programmierer. Mein Verständnis für solche Sachen ist entsprechend begrenzt. :)

  • Da geht es mir wie dir. So ganz bin ich noch nicht hinter die Sinnhaftigkeit der params gestiegen. Die wirken auf mich irgendwie umständlich und machen den Code für mich nur schwerer lesbar. Aber ich bin auch nur ein Gestalter und kein Programmierer. Mein Verständnis für solche Sachen ist entsprechend begrenzt.

    Ich bin ja weder das eine noch das andere, aber Ansich ist das eher was für die Gestalter würde ich mal denken..
    Da kann schon vieles eher ungenauer werden - sieht man ja am Beispiel, ich verwende ein include an zwei Stellen und prügel dann bestimmte Codeteile mit visible = false dazu das er tot
    mit drin hängt. Da haben sicher Programmierer eher was dagegen als Gestalter;)..
    Ein paar Stellen gibts schon wo es sinnvoll ist, vor allem wenn eben verschiedene Positionen fürs selbe hast, oder meinetwegen du hast 10 Listen die gleich sind bis auf die ID (weil es Core ID´s sind oder contents enthalten die an eine ID gebunden sind).

    Da ist es schon klasse das zu includedieren mit der ID als Parameter. So kann man dann Favoriten, zwei unterschiedliche eigene Dialoge und noch ein Einstellendialog der zwei dieser Listen enthält
    eben mit so etwas Abfrühstücken.

    und einfach mit ID Angaben überall verwenden:


    Code
    <include content="Common_dialogIconlist772">
                <description>layout</description>
                <param name="id" value="450" />
            </include>

    Allerdings geb ich dir dann wieder recht - da man ein halbes Jahr später keinen Plan mehr hat ob und wie was zusammenspielt.
    Einfach dann wo breiter machen ohne zu wissen welcher hintergrund wieder wo dann auch geändert werden muss führt dann schnell dazu das es ohne kontrolle genausowenig bringt wie direkt im Code.

    Ich würde wenn ich bumblebee wäre das auch einzeln machen item und focusedlayout..
    Er hat halt leider teils Animierte und auch was ohne drin. Du musst dann halt zweimal alles ändern und die Liste ist schon etwas länger (anders für Episoden, Musikvideos usw..)..

    Grüße

  • Parameter sind am ehesten noch mit Variablen ($VAR) zu vergleichen, denn die sind dazu da, z.B. ein Include zu parametrisieren - oder mit anderen Worten: einzustellen. Konstanten sind per se konstant, d.h. sie sind nicht veränderbar. Im herkömmlichen Sinn sind sie eigentlich auch nur Aliases (z.b. const 'black' -> #00000000 oder const 'myspecialcolor' -> #12345678). Eine 'veränderbare Konstante' gibt es per Definition nicht: das ist eine Variable.

    AZi (DEV): Nexus auf LibreElec | Asrock J4205 | 4 GB RAM | 128 GB Sandisk| Rii mini
    DEV: PC Ubuntu 20.04 | Matrix
    AZi: Tanix TX3 | Android/CoreElec Dualboot (EMMC), Nexus
    WoZi: Nexus auf LibreElec | Asrock J4205 | 4GB RAM | 128 GB Sandisk SSD | Atric IR | URC7960
    NAS: unRaid, 3x6TB, 2x12TB | TV-Server: Futro S550 mit Hauppauge QuadHD DVB-C
    PayPal: paypal.me/pvdbj1

  • Parameter sind am ehesten noch mit Variablen ($VAR) zu vergleichen, denn die sind dazu da, z.B. ein Include zu parametrisieren - oder mit anderen Worten: einzustellen. Konstanten sind per se konstant, d.h. sie sind nicht veränderbar. Im herkömmlichen Sinn sind sie eigentlich auch nur Aliases (z.b. const 'black' -> #00000000 oder const 'myspecialcolor' -> #12345678). Eine 'veränderbare Konstante' gibt es per Definition nicht: das ist eine Variable.

    Die Programmierer sind einfach super im Erklären;)..

    Die Definition Einstellen ist allerdings eben genau das was sich schnell in anders schreiben verwandeln kann. Einen Dialoghintergrund bei dem ich letztendlich alle vier Positionswerte als Parameter angeb und nur noch die texture und die Farbe fix ist, kann ich auch genauso "alt" schreiben und den "nicht Einstellbaren" Teil einfach in die Tags schreiben. Da ändert sich ja Überhaupt nichts dran.

    Mit Constanten wollte ich drauf raus das man so minimal versuchen kann Abhängigkeiten Darzustellen:
    Inlcudes sind ja nie alleine unterwegs. Einfach mal im Dialoghintergrundinclude mit Titel, Logo und Button im Estuary, wo es ja sinn macht mit den Parametern den Abstand des Titels ändern
    reicht ja nicht. Alles was darunter käme muss ja dann logischerweise "auch woanders hin".
    Sowas erreich ich am ehesten wenn man es mit Constanten vereinheitlicht.

    Ich hab das dann eher damit gelöst, indem ich dann abhängige constanten Anlege für Dialoge wie <left>bottom.dialogbar.left</left> mit dem ich dann so etwas wie Listen und labels global
    einen "linken Einzug" verpasse da auch an anderen Stellen wieder Buttons, Radiobuttons usw. einen textoffset haben und brauchen.
    Zieht man das konsequent durch kann ich im Prinzip mit Ändern von wenigen Werten erst mal alles gleichzeitig "umpositionieren".

    Mit einzelnen Includes bei denen ich letztendlich alles irgendwann dazuschreib, kann ichs gleich auch ohne machen oder mit zwei drei "kleineren" auch mit der alten Variante.
    Bis auf eben die Dinge wie "andere ID" oder "anderer Labeltext".

    Ich hätte jetzt eher Gedacht Programmierer haben eher was gegen Parameter. Wie in deinem letzten wo es nicht ging, führts ja oft dazu das man zum Schluss ein Monsterinclude "Totparametrisiert" und in einem PVR Content dann 80% gar nicht angezeigt wird. Das kann ja auch nicht der Sinn sein (zumindest nicht für mich und wenns nicht unbedingt sein muss wie manchmal bei Widgets).

    Auch nicht zu Unterschätzen ist der (für mich) große Nachteil der Parameter:
    Ich kann kein include mehr "überschreiben". Mit der alten methode kann ich Beispielsweise in jeder verwendeten Stelle wo es enthalten ist, durch die Tagreihenfolge noch Beeinflussen ob ich einen einzigen Wert nicht will.
    Ich weiß gar nicht ob das Bekannt ist.
    Hab ich jetzt ein include das den Font enthält, Beispielsweise für Dialog Titel, kann ich vor das include auch Meinetwegen in was "kleinem" wie dem Confirm Dialog, einen anderen Font angeben.
    Da der Wert schon vorm include gesetzt wurde, ignoriert es damit den font tag im include.
    Damit kann ich auch leichter Einzelfälle Umschiffen wie das Beispiel. Mit Parametern muss ich so schon Überlegen ob ichs akzeptier, alle Stellen nachträglich ändere was dann dazu führt das ichs in 9 von 10 Stellen unnötig dazuschreiben muss (wo es vorher schon passte), oder dort ohne das include Arbeiten.

    Und ganz wichtig auch noch zwei jahre später wissen das ich den font da nicht größer machen darf weils sonst dort noch weniger passt;)..

    Und dazu noch der Nachteil wie im Beispiel. Sowas wie global in allen labels das Scrollen ausschalten und per inlcude wieder einschalten, z.B nur im Focus einer Liste oder nur beim bestimmten Titeln,
    geht dann auch nur wenn ich sowas wie Parameter Scroll = true/false in jedes einzelne include schreiben würde. Auch wenn 2/3 sowieso false sein sollen.
    Parameterincludes sind ja meistens "größer" mit ganzen Controls und nicht nur mit Codeteilen..

    Aber letztendlich muss es ja jeder selber entscheiden was besser zu Ihm passt.

    Grüße

Jetzt mitmachen!

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