Dann eben ein Blättchen Zitronenmelisse. 
Moment… bitte WAS?
Soll das heißen, ich brauche pro Player vier unterschiedliche Rahmen mit entsprechenden Fernsteuerung-IDs?
Ich sag’s mal so: Man kann mit den verschiedenen Ebenen im Layout schon ein paar nette Sachen anstellen und es kostet was an Aufwand, der sich gerne lohnen darf.
Aber sollte ich nicht gerade komplett auf dem Holzweg sein: Sorry, hier stößt die Liebe doch an Grenzen.
Würdest du mich bitte erhellen?
Da es kleine dezidierten „Rahmen“ als GUI-Elemente gibt, nimmst Du vier längliche Felder und ordnest sie entsprechend an. Wo ist das Problem? Ich habe bei meiner Uhr 60 Felder, und das Programm stürzt trotzdem nicht ab.
Du könntest natürlich, wenn es gelingt, je ein Feld hinter den Player setzen und das Skript entsprechend ändern.
Ach weißt Du, Uli, ich hab’s mir überlegt: Ich liefere eine gang- und brauchbare Lösung, und Du, dessen Scripting-Licht nicht das allerhellste ist, p*ßt mich an, weil Dir für Deinen Geschmack ein paar GUI-Elemente zuviel auftauchen? Meine Lösung: Ich schreibe (Skripte) nur noch auf bilateraler Ebene. Wenn überhaupt.
Ich bin zwar engagiert, aber im Kern dennoch mitunter faul.
mAirList sowie andere Soft- und Hardware soll mich beim webcasting unterstützen und mir keine Zusatzarbeit bescheren. Wenn ich etwas einrichte, ist es einmalig bzw. mit Langfrist-Perspektive, aber auch dieser Aufwand stößt halt an Grenzen.
Da hat jeder so seinen persönlichen threshold. 
Mit je einem Rahmen (leeres Textfeld, Rahmenbreite 3) um die beiden Player komme ich ja noch klar. Und wenn sich dieser Rahmen via Script, getriggert vom Statuswechsel, verschiedentlich einfärben lässt: Supi!
Bis hierhin hatte ich meine Antwort vorbereitet und wurde dann durch ein sehr langes Telefonat unterbrochen.
In der Zwischenzeit…
Hier liegt noch ein Screenshot, der meine Visualisierung und (missverstandene) Idee darlegen soll.
Das kommt alles später; jetzt lege ich mir das erst mal virtuell unters Kopfkissen und hoffe, dass sich in ein paar Stunden die Gemüter wieder etwas beruhigt haben.
Gute Nacht, einen schönen Start in den Samstag und bis später.
Wer wie Du Anprüche stellt, muß halt für deren Umsetzung auch mal seinen Allerwertesten heben. Luxusausstattung kommt nicht per Fingerschnipp.
Ich habe noch nicht einmal argumentiert.
Ich würde das gerne mal auseinanderdröseln. Vielleicht gibt es irgendeinen Punkt, den ich übersehen oder gar missverstanden haben könnte.
Es war @Myka, der mich auf den Trichter mit den Rahmen um den bzw. die Player brachte:
Das mit dem Radius lassen wir mal außen vor (“ignore”).
Okay, ich hab’s getestet und fand es nice:
[Player]
BorderColor=White
// alternativ auch getrennt
[Player0_0]
BorderColor=Green
[Player0_1]
BorderColor=Orange
Blöderweise ist das nicht dynamisch abhängig vom PlayerState, was ich schade finde.
Bei der background color der Player geht das nämlich:
<Player State>Color |
Background color for the particular state |
(reference:skin.ini_reference [mAirList Wiki])
Na schön, fällt aus wegen isnich.
Nun hat Tondose einen workaround mitsamt Script gebastelt.
Die Idee dahinter: Ein leeres Textfeld hinter jedem Player. Dieser Rahmen mit der Stärke 2 wäre sogar noch besser erkennbar. Ist zwar ein wenig Fummelei im Layout Designer, aber einmalig machbar.
Was mich aus der Bahn geworfen hat, war dann das hier:
Na gut, an den vier Rahmen entzündete sich ein Konflikt:
Das unterschreibe ich sogar.
Was ich aber nicht so wirklich verstanden habe, war die Logik des Layouts (das wurde doch nicht durch das Skript gesteuert, oder?). Denn die…
…müssen ja auf verschiedenen Ebenen im Layout liegen, oder etwa nicht?
Ich habe also je Player vier leere Textfelder (warum eigentlich vier?), die je nach Status des Players… aktiv werden?
Meine Denke, und da laufen wir ganz offensichtlich auseinander, war:
Ein Hintergrundfeld, dessen Farbe sich je nach PlayerState ändert.
Da passten die vier Elemente je Player irgendwie nicht rein. Wir waren auf unterschiedlichen Wegen unterwegs.
Mein Vorschlag lautet: Differenzen beseitigen, Klarheit schaffen. Da haben dann auch andere was davon.
Ich persönlich fände es tatsächlich besser, wenn die Sache mit der <PlayerState>BorderColor (mein Wunsch) analog zur <Player State>Color eingerichtet würde. Vielleicht mache ich ja ein feature request daraus.
Frei nach @calypso60: Das sollte doch möglich sein (müssen).
Vielleicht bringt es etwas mehr Klarheit, dass wir diese beiden Perspektiven jetzt einfach mal offengelegt haben.
Ja klar, und weiter? Sogar die Player liegen auf verschiedenen Ebenen.
Weil so ein Player vier Seiten hat? (Du kannst es auch mit dreien machen, dann ist der Player halt durchgestrichen.)
Deren Hintergrundfarbe sich jeweils ändert.
Welche beiden?
Wer zufallsgesteuerte Timeslots wünscht, aber zu „faul“ ist, ein paar Felder ins Layout einzubauen, trifft bei mir (alter weißer Mann) nicht auf Verständnis. Im Gegenteil.
Es bleibt dabei:
Ach, eben!
Jetzt verstehe ich deine Herangehensweise - und den Unterschied zu meiner.
Eigentlich sind wir gar nicht so weit voneinander eintfernt.
Du bastelst an jeden Player je vier längliche Felder an.
Klar, vier Seiten…
Ich erzeuge ein einziges Feld in der Größe des Players.
Der Player schrumpft marginal, so dass der überstehende Teil des unter dem Player liegenden Feldes wie ein Rahmen wirkt; in Wirklichkeit ist es ein “Überstand”.
Im Rest wiederum sind wir uns einig, und der Schreck über die Anzahl der Bildschirmobjekte hat sich auch gelegt.
Missverständnis ad acta.
Momendemaa…
Man schleppt ja im Laufe der Jahre, Versionen und Generationen so einige Altlasten mit sich herum. Das ist bei der skin.ini nicht anders.
Beim aufräumen ist mir aufgefallen, dass es Blöcke mit Farbdefinitionen in den Playern gibt, die schon älter sein müssen (ich würde heute teilweise zu anderen Farben greifen). Und ausgerechnet dort finden sich NextBorderColor= sowie PlayingBorderColor=.
Das habe ich damals doch nicht einfach so zum Spaß da reingeschrieben!
@Torben
Könnte es sein, dass es diese Option bis einschließlich v6 mal gab, die dann aber im Zuge der…
Wir hatten das Thema gerade gestern (da stammt auch das Zitat her).
Sollte das so sein, kann ich mir das feature request ja sparen.
Hast du da eine kurze Info für mich?
Enorm neu:
Vielen Dank für den Hinweis; vermutlich ist der in der Kaskade untergegangen.
Ich weiß es einfach nicht mehr.
Näheres gerne per PN, da es hier sonst zu OT wird.
Hi, Uli,
dumm, wie ich war, hatte ich mir die Einstellungen nicht notiert, habe sie aber eben wiedergefunden. Ich habe seit heute einen neuen PC und habe die Einstellungen (siehe unten) wiedergefunden - hier, dank deiner Hilfe und der einiger anderer. ABER: Was ich nicht mehr weiß, ist, wie ich die Zeilen komplett einfärbe - nicht nur die Farbe am Anfang der Zeile, sondern die gesamte Zeile. Wenn ich einen Text eintrage, suche ich nach dem Eintragen die Farbe aus. Die soll aber die ganze Zeile einfärben, nicht nur den dünnen Strich am linken Rand. Könntest du mir bitte sagen, wie das ging/geht?
Vielen lieben Dank.
Gruß
Carsten
[Playlist0]
FontName=TimesNewRoman
FontSize=14
RowHeight=44
TitleDisplayMode=VSplitArtistTitle
BackColor=#FFFFFF
PlayingBackColor=#CCFFCC
NextBackColor=#CCCCFF
SelectedBackColor=#99CCFF
PlayingFontColor=#000000
NextFontColor=#000000
SelectedFontColor=#000000
DisabledFontColor=#666666
IconMargin=0
UsePlayerColors=off
ColumnOrder=title,duration
ColumnWidths=300,60
HeaderVisible=on
GridLines=on
ArtistFontStyle=1
TitleFontStyle=0
Nicht aus der Hüfte geschossen, aber als Anhaltspunkt:
Der dünne Strich links heißt “Color Ribbon” und wurde - Überraschung! - mit v6 eingeführt. Da gab es weder einen dark mode noch einen Live Skin Editor.
As a new design element, there is a colored vertical band running down the playlist, which will reflect the item color of the individual item colors, as an alternative to the row background color. For many designs, it will be look much nicer to keep the same background color for all rows, and only alter the ribbon color according to the item color. It is also possible to adjust the ribbon color through skin.ini, using
RibbonColorentries similar to the existingRowColormechanism.
(https://wiki.mairlist.com/release:mairlist-6.0?s[]=ribbon#playout)
Ohne nachgeschaut zu haben, denke ich, dass das eher ein Fall für die Konfig ist (nein, nicht die Systemsteuerung, da es hier um die Playlist geht). Die skin.ini mag zwar färben, aber was genau nun eingefärbt werden soll, ribbon oder row, das wird, so vermute ich, an anderer Stelle definiert.
Die dürften so nicht funktionieren…
Richtig wäre so:
BackgroundColor=#FFFFFF
PlayingFileRowColor=#CCFFCC
NextFileRowColor=#CCCCFF
SelectedRowColor=#99CCFF
Keine Ahnung, wie du auf “Back” gekommen bist… Oder habe ich das falsch verstanden @UliNobbe und man kann mit “Back” irgendetwas triggern, das ich noch nicht kenne?
Ganz bestimmt, nur hat das höchstwahrscheinlich nichts mit mAirList zu tun. 
Der Tiefpunkt wäre erreicht, wenn hier zu allem Überfluss auch noch eine so genannte “künstliche Intelligenz” (gibt es nicht!) im Spiel wäre.
Da ich Carsten aber nicht zu nahe treten möchte: Keine Ahnung.
Randnotiz: Ich würde es sehr begrüßen, wenn ihr (wir alle!) Code-Zeilen auch in Code formatieren würdet.
[Playlist0]
FontName=TimesNewRoman
FontSize=14
RowHeight=44
TitleDisplayMode=VSplitArtistTitle
BackColor=#FFFFFF
PlayingBackColor=#CCFFCC
NextBackColor=#CCCCFF
SelectedBackColor=#99CCFF
PlayingFontColor=#000000
NextFontColor=#000000
SelectedFontColor=#000000
DisabledFontColor=#666666
IconMargin=0
UsePlayerColors=off
ColumnOrder=title,duration
ColumnWidths=300,60
HeaderVisible=on
GridLines=on
ArtistFontStyle=1
TitleFontStyle=0
bzw.
BackgroundColor=#FFFFFF
PlayingFileRowColor=#CCFFCC
NextFileRowColor=#CCCCFF
SelectedRowColor=#99CCFF
Es erhöht die Lesbarkeit im Forum.
Das Zauber-Icon dafür sieht so aus:
Vielen lieben Dank, und viel Erfolg mit DaSkin.
Hi, Uli,
ja, du hast Recht: Das war nicht die Skin Ini, sondern die Einstellung in der Konfiguratioin. Hab den Haken bei “Elemente Farben als Hintergrund verwenden”. Jetzt ist wieder alles so, wie es sein soll.
Danke dir herzlich.
Gruß
Carsten
Hi, Myka,
hmm, komisch. Es ist genau so, wie ich es haben wollte. Alles passt.
Ich habe noch mal aus “Back” “Background” gemacht - nichts hat sich verändert.
Aber danke für deine Anmerkungen. Werde das noch mal durchprobieren.
Gruß
Carsten
Die Fakten sprechen gegen dich, sorry.
Meine Vermutung: Da ist irgendwo in deiner skin.ini noch (mindestens) ein Wurm 
drin. Du kannst @Myka schon was glauben.
Probe aufs Exempel:
(BackColor)
(BackgroundColor)
Fehlersuche:
Wenn irgendwo eine nicht existente Anweisung unterwegs ist, wird sie ignoriert. Das betrifft Schreibfehler (ja, sogar case sensitive!) wie Fantasie-Anweisungen gleichermaßen.
Du hast [Playlist0] geschrieben - warum? Hast du mehrere Playlisten am Start?
Oder beißt sich da vielleicht was mit [Playlist]?
BackgroundColor=#FFFFFF (ergo: weiß) ist im light mode irgendwie sinnfrei.
Erinnert mich entfernt an die ostfriesische Kriegsflagge (“weißer Adler auf weißem Grund”, Überlieferung). In dem Fall “funktioniert” sogar BackColor. 
(scnr)
Wieder ernsthaft:
mAirList “liest” die skin.ini von oben nach unten, und “der letzte Eintrag gewinnt” (O-Ton Torben).
Das hat einen ganz praktischen Grund: Oben setzt du generelle Einstellungen und weiter unten dann gezielte Ausnahmen.
[Playlist]
RowColor=$Standardfarbe
NextRowColor=$Bereitschaftsfarbe
PlayingRowColor=$HierspieltdieMusikfarbe
skin.ini dementsprechend durchforsten, ob da nicht irgendwo noch eine Anweisung im Keller herumlungert, die die ganze Arbeit weiter oben durchkreuzt.Ich mache gerade Frühjahrsputz in meiner skin.ini, und es ist a) eine Heidenarbeit und b) garantiert nicht vergnügungssteuerpflichtig.
Ich bin gespannt auf deine Ergebnisse.
Viel Erfolg!
Nachtrag
(extra Beitrag; kann leichter gefunden, mit einem Lesezeichen versehen, zitiert und verlinkt werden)
Eventuell kam es hier noch nicht zur Sprache, aber die Sache mit der Farbwahl im Live Skin Editor ist meiner Meinung nach so 'ne richtig geile Kiste (hat schon mal einer Torben dafür gelobt? Nein? Dann tu ich’s jetzt!).
Zum einen kann man mit einem Doppelklick auf z.B. #0000FF den Farbcode sofort hervorheben, kopieren oder ggf.ersetzen. Schon probiert?
Die # wird nicht markiert; es wird nur der Hex-Code kopiert und eingefügt.
Zum anderen kann man in der Farbwahl, wenn ein Farbeintrag erkannt und erwartet wird, in der Direktwahl doppelklicken.
Die # verschwindet und wird durch eine “sprechende” Farbe bzw. Auswahl ersetzt.
NextFontColor=Orange
