Beiträge von Marc0810

Hey,

Das ist leider alles andere als Einfach;). Die komplette Bedienlogik der OSD Anzeigen ist auf x- Fenster verteilt abgestimmt nur durch Sichtbarkeiten.
Das sind also alles keine Bedienungsänderungen sondern ist eher die Frage was wo eingblendet wird.

DialogSeekbar und VideoOSD müssten das hier sein.

Die Anzeige bei Pfeil hoch wäre die Seekbar.
Du müsstest dort das visible ändern
Das sieht so im Estuary aus:
Zeile 4 im Mimic geändert zu

<visible>Player.Seeking | Player.DisplayAfterSeek | [Player.Paused + !Player.Caching] | Player.Forwarding | Player.Rewinding | Player.ShowInfo | Window.IsActive(fullscreeninfo) | Window.IsActive(videoosd) | Window.IsActive(musicosd) | Window.IsActive(playerprocessinfo) | !IsEmpty(Player.SeekNumeric)</visible>
	<visible>!Window.IsActive(sliderdialog)</visible>
	<visible>Window.IsActive(visualisation) | Window.IsActive(fullscreenvideo)</visible>

Und damit das Video OSD nicht kommt müsste man das ebenfalls anpassen.
Kopiere ich in Zeile 23 in die group das des Estuary scheints zumindest dort schon mal zu passen.
Aus Estuary:

<visible>![Window.IsVisible(SliderDialog) | Window.IsVisible(fullscreeninfo) | Window.IsVisible(osdaudiosettings) | Window.IsVisible(osdvideosettings) | Window.IsVisible(OSDAudioDSPSettings) | Window.IsVisible(VideoBookmarks) | Window.IsVisible(playerprocessinfo) | Window.IsVisible(osdcmssettings) | Window.IsVisible(PVROSDChannels) | Window.IsVisible(PVROSDGuide)]</visible>

Das ist aber ein Schnellschuss. Zu dieser Logik muss man den Skin schon super gut kennen und auch wissen was wo kommen soll/muss.

Zu dieser OSD Logik gehören noch weit mehr Fenster wie du siehst.
Die ganzen Einstellungsdialoge für Bild/Audio, Laut/Leise, Chaching, Seeking, Video und MusicOSD Bedienknöpfe, Infodialoge, PDF Guide und Channelinfo, Slider für AudioDelays,
Untertitel, Visualisierung bei Musik und sicher noch einige die ich vergessen hab.
Jedes Fenster muss gro´ßtenteils mit solchen "Gegenläufigen" Sichtbarkeiten Ein- oder Ausgeblendet werden wenn andere Erscheinen.
Das ist mit finde ich die größte Herausforderung die ein Skin hat da eine Logik zu Erarbeiten und den Überblick zu behalten.

Vielleicht hast du aber Glück und damit gehts schon;).
Für mehr fehlen mir die Kenntnisse im Skin die man eigentlich nur als Nutzer haben kann.

Grüße

Zitat von vadulli

Oder hab ioch das mit Export und Import der falsch verstanden ??

Der Export von Textinfos als NFO und/oder Artworks ist eine Sicherung aller Datenbankinfos jedes einzelnen Eintrages der Datenbank.
Jeder Eintrag (Mediendatei) bekommt dabei eine Einzeldatei mit allen Infos die in der Datenbank vorhanden sind.
Liest man danach mit dem Advancedsetting Importwatchedstates diese Dateien in eine leere Datenbank ein hat man genau denselben stand wie vorher.
Das ist oft einfacher als andere Vorgehensweisen.

Hättest du nun unterschiedliche Gesehen Infos in deinen 3 Clients wäre das die falsche Wahl.

Alternativen gibts natürlich immer.

Ein Gesamtexport (danach wird man beim Export Gefragt) z.B. - dabei wird die ganze DB in eine große xml geschrieben.
Bei der kann man dann z.B. per suchen und ersetzen auch aus G:\\Filme z:\Filme machen und wieder einlesen.
Zumindest in der Therorie - hab ich bisher auch nur einmal gemacht und da dauert er import dieser xml gruslig lang..

Direkte Änderungen in der DB gehen sicher auch - da müsste ein SQL experte was zu sagen.
Dort mit einem Viewer ein suchen und ersetzen Befehl schreiben geht sicher auch.

Ansonst versuch macht Klug.
Ohne wird das beste Vorgehen das dir liegt keiner wissen können.

Vorgehen z.B. nach der NFO Methode wäre:

• Alte DB sichern - einfach die MyVideos1xx.db sichern durch kopieren.
• Einen Export als NFO Dateien mit Artworks anstoßen.
• Filme Verschieben aufs NAS, wichtig dabei zu erwähnen das man mit der NFO Methode vollkommen unabhängig wäre.
  Auch mehr als ein Pfad ändern ginge dort. Also nicht nur x:\\Filme zu z:\\Filme, sondern auch wenn man Meinetwegen noch neue Gemischte pfade wie
  z:\\Filme\HD für einige.
• Neue DB anlegen und einlesen mit dem Advanced Setting Import watched states.

Danach ist alles wie früher. Diese DB Datei und den ordner Thumbnails kann man danach sogar direkt auf die anderen beiden Clients verteilen und alle haben denselben Stand.

Aber eben alles mit der Annahme das alle 3 wirklich genau dieselben Infos haben. Gehört da einer der Frau die andere gesehen Statusse hat klappt das nicht.

Vielleicht solltest du dich in die Datenbank Sektion verschieben lassen.
Dort kann dir da einer bestimmt eine Pfadersetzung direkt in der Datenbank ausknobeln.
Davon hab ich keine Ahnung wäre aber sicher die einfachste Möglichkeit für einfach Pfadänderungen.

Ich nutz solche Aktion aber auch gerne mal um Infofehler nochmal durchzugehen, z.B. Genres mal ausmisten und solche Dinge.
Und ab und an eine Frische DB ohne irgendwelche Leichen ist auch kein Fehler Denk ich.
Aber das sieht jeder etwas anders.

Grüße

Zitat von vadulli

Gibts da irgedwo eine Anleitung ? Ich hab das noch nich gemacht .
Wir funktioniert der Export ?

Wenn dir unsicher bis würde ich sowas erst mal testen - falls man Windows zur Verfügung hat ist das über Portable als "Zweitinstallation" super einfach.
Da würde ich mal danach suchen und bevor dabei was schief geht erst mal damit einige Versuche starten.

Export der Datenbank findet man hier
http://kodi.wiki/view/Import-export_library

Danach wenn man Bilder ebenfalls mit Exportiert hat liegen sämtliche Infos in den Film und Serienverzeichnissen.
Sofern man alle Filme in eigenen Verzeichnissen hat (wie sich das verhält wenn man alle in einem Verzeichnis hat, speziell Filme weiß ich nicht).

Danach musst du dir dann die Advanced Settings ansehen

Vereinfacht gesagt ist das eine XML Datei in deinem Userdata Folder die Befehle/Settings enthält:
Hier muss dann unbedingt auch angegeben werden das Kodi den Status auch importieren soll (Standard ist ohne).
http://kodi.wiki/view/Import-export_library

Das würde ich mal mit wie gesagt wenn möglich portable ausknobeln und danach erst das "Produktivsystem umstellen".

Dabei ist es sogarmöglich die Datenbank aus Portable Versionen (solange es dieselbe Kodi version ist) einfach zu kopieren ins Prodktivsystem.
Solange die Quellen gleich bleiben spart man sich dann sogar das erneute einlesen.

Grüße

Zitat von SkyBird1980

Ich sagte ja nicht das es so nicht geht. Bei jedem neuen Clienten reduziert sich halt der Aufwand in "Addon installieren und synchronisieren"

wollte es nur der vollständigkeit erwähnt haben;)..
Für mich liest es sich eher nach einer einmaligen Geschichte als nach "ich habe 5 clients ohne zentrale DB". Und deswegen extra über trakt zu gehen lohnt sich dabei ja evtl. weniger.
Der interne weg ist für sowas (mache ich bei jeder neuen Kodiversion so) für mich einfacher als über ein Addon.

Jetzt hat er ja bei Varianten und kann sich entscheiden .

Grüße

Zitat von SkyBird1980

Moin, ich nutze für so etwas das Trakt.tv Addon. Damit kann ich auf allen meinen Clients die gesehenen Episoden und Filme synchronisieren.

Da würde ich doch lieber die DB exportieren in die jeweiligen Filmquellen (Export in einzelne Dateien als NFO´s, alternativ auch mit allen Artworks). In den NFO´s stehen ja die Info genauso.
Dann alles aufs NAS, DB neu aufbauen mit Advancedsetting

<importwatchedstate>false</importwatchedstate> <!-- import previously exported playdate and playcount from .nfo files. Defaults to false -->

Und neu einlesen. Da ja nfo´s bevorzugt werden hast danach auch ohne Addon wieder die Gesehen Status anzeigen wie vorher.
Das geht auch super schnell je nach Rechner.

Grüße

Zitat von Cherryman

Ja, das wäre in der Tat ein sinnvolles Feature und dürfte so schwer denke ich nicht umzusetzen sein.

Auf den ersten Blick sicherlich. Mir fehlen die Sprachkenntniss um in Englisch drüber zu Diskutieren. Ein großer Einwand wäre das die Geschwindigkeit, mehr noch bei Textboxen aber auch bei
labels von Textgröße, Zeilenabstand und auch der Länge abhängen sollte.
Wer das allerdings per default.xml regelt ignoriert das zumindest bei labels ja eh schon.
Aber in der Praxis ist es schon so das eine globale Geschwindigkeit bei einem 800 pixel langem Label nicht unbedingt gleich sein kann wie in einem mit 200.
Bei Textboxen noch viel mehr. Stell dir vor 10 zeilen über die Gesamte Bildschirmbreite scrollen genauso schnell wie zwei in den Einstellungsbeschreibungen.

Und dann fängt es schon wieder an zu kompliziert zu werden wenn man das über relationale Werte machen würde die die textlänge noch mit einbeziehen.

Aber nen versuch ist es sicher wert wer des englischen mächtiger ist als ich.

Grüße

Den Debugmodus hab ich ja nie verwendet. Anfangs wußte ichs nicht und danach wars zu spät;).
Das wäre aber mal ein richtig sinnvolles Feature die Scrollgeschwindigkeit ebenfalls per Advanced setting sebst Einstellen zu können.
Wenn man so drüber Nachdenkt fehlt das wirklich.
Wenn man Textgrößen auswählbar macht mit verschiedenen Fontsets, sollte man auch in Fließtexten wie Plots oder zu langen Texten
dasselbst einstellen können wie schnell man lesen will.

Aber die ganze label, textboxen Geschichte ist ja teils in skinengine sowieso ein Graus das etliche Probleme bereitet.
Ob sich da einer mal Rantraut bleibt abzuwarten.

Grüße

Ordnerweit suchen ist da das Zauberwort. Dann ist man recht flott durch.
Nur da wirds dann schon wieder kompliziert da man für sowas eigentlich den code genau kennen muss um zu wissen welche view was sein soll und
welche fenster welche sind.

Meistens klingt es aber schwerer als es ist;).. Ändern und Aktualisieren mit Reload Skin kann man ja jederzeit bis es einem passt.

Grüße

Zitat von DaVu

Habe es gerade bei mir mal aus Spaß auf "1" gesetzt und es ist gähnend langsam

da muss man aber aufpassen:

"Defaultwerte" werden durch "Codewerte" überschrieben und bevorzugt.
Schreibt da irgendeiner im Titel Scroll False rein (oder in ner Dialogüberschrift) dann werden die Defaultwerte dadurch für dieses eine Label ignoriert.

Man kann sichs so vorstellen das erst Default.xml code reingeschrieben wird in jedes Controltype das dort vorhanden ist.Danach überschreibt dann "Fenstercode" diese Werte.
Da muss man sich dann Notgedrungen mit suchen alle <scroll> und <scrollspeed> einzeln anschauen im Code und entscheiden was man wo will.

Grüße

Hey,

Das ist im Skincode angegeben:

scrolltime bei Textboxen wie Plots, Containern und Grouplisten
scroll= true/false und scrollspeed = Defaultwert 50, weniger ist langsamer bei Labels, Buttons, Togglebuttons usw.

Je nach Skinaufbau muss man das in jedem Label einfügen oder es wird global über die defaults.xml gesteuert.

Wie das im Defaultskin ist muss man Nachschauen.

Grüße

Zitat von hoppel118

danke für die Erläuterung. Schade, das Pinboard hat wirklich Potential. Naja, mal sehen. Vielleicht kommen da noch ein paar Funktionen in zukünftigen Kodi-Versionen.

Hey,

Ist purer Skincode, also eher nicht;).. Wenn jeder selber per Skin ein Contextmenü bauen könnte wäre das zwar klasse, aber sicher ne rießen würgerei das das überall läuft.
Das Ding hat global glaube ich über 100 Mögliche Buttons für verschiedene Fenster und Bedingungen. Wenn man da noch selbst mit rein "Wurstelt" kommt sicher nichts gutes bei raus.

Entfernen im Videofenster geht sicher wenn ein Element bereits vorhanden ist oder sowas wie löschen nach dem Anklicken (bei Filmen z.B.).

Grüße

Zitat von hoppel118

zu 4. Es wäre schön, wenn ich an den Pinboard-Widgets überhaupt ein Kontextmenü hätte. Das fehlt mir dort.

Hey,

Das contextmenü und wann es überhaupt kommt regelt Kodi selbst im Core. Mit 17 wurde das im Home nur auf "content Provider" Erweitert.
Das funktioniert nur dort und nicht bei herkömmlichen Listen mit x EInträgen die aus dem Skin kommen.
Das Pinboard ist ja so ein Liste die aus x items besteht die nur Angezeigt werden wenn sie Belegt sind, und keine Liste die aus einer Pfadangabe
mit dem content Provider durch Kodi entsteht.

Da hat man nicht mal die Möglichkeit etwas "künstlich" auf die C Taste zu legen - sowas bietet Kodi nicht an.

Grüße

Zitat von ulo

Zumindest die Konzerte bekomme ich nicht problemlos per Youtube... ;=)

und genau das ist es ja;).. Wer setzt sich schon hin und nimmt Schnipsel von liedern in eine interne Datenbank auf. Solang es auch noch alternativen gibt, keine vernünftige Scrapper usw.. Konzerte sind ja auch nur als Krücke innerhalb von Filmen Standard.
Das ist alles recht Merkwürdig und folgt auch keiner Logik.

Ein Konzert als Film, ohne Interpret aber mit Darstellern getaggt als Film mit Genre Musik und einzeln per "Node Pfad" wieder aus Filme extrahiert, dafür aber mit mehr Tags wie Regie und Country.
Im Gegenzug ein Videoclip das dann wieder Tags wie Interpeten mitbringt, dafür aber eher ein Musikcover hat und keine Onlinequellen als Infobezug hat.

Und immer wieder die Gefahr das man sich doch mal ransetzt, alles über den Haufen wirft oder streicht.
Dazu muss man halt sehen das Kodi soweiso schon zuviele content types hat und skins dadurch immer schlimmer werden:

Sieh es mal so, eine Liste für DB views kann mittlerweile den Inhalt haben:

movies, videos, tvshows, episodes, seasons, genres, years, tags, years, collections, games, addons, files, pictures, albums, songs, artists, musicvideos

Und das sind nur die die mir gerade einfallen und es ist beileibe nicht so das eine für alles gelten kann (zumindest in seltenen Fällen muss man jeden content einzeln "anders" gestalten)

Wenn es wirklich auch noch in Videos einen "richtigen" content gäbe der Konzert und Clips mit Interpetentags und allem Abbildet, wirds ja noch schlimmer;).

Grüße

Zitat von ulo

Die Fehler/Versäumnisse treten eben auch schon im ursprünglichen Estuary-Skin auf

ich kann es leider nicht testen da ich sowas gar nicht hab, wenns aber schon im original nicht geht scheint es ja eher ein Kodi problem zu sein.
Da wäre ein Skinfehler ja sicher aufgefallen im letzten halben Jahr.

Sorry, aber mehr kann ich dazu auch nicht sagen da sich in der Richtung nicht wirklich viel bewegt. Es war sogar mal im Gespräch das ganz zu Killen weils kaum einer nutzt.

Grüße

Zitat von ulo

"library://music/musicvideos"

eben und diese Vorgaben stimmen wahrscheinlich nicht. Da hilft auch kein Neuaufbau sondern der Skin muss korrigiert werden.

MusicVideos 	videodb://musicvideos/
MusicVideoGenres 	videodb://musicvideos/genres/
MusicVideoTitles 	videodb://musicvideos/titles/
MusicVideoYears 	videodb://musicvideos/years/
MusicVideoArtists 	videodb://musicvideos/artists/
MusicVideoAlbums 	videodb://musicvideos/albums/
MusicVideoDirectors 	videodb://musicvideos/directors/
MusicVideoStudios 	videodb://musicvideos/studios/
RecentlyAddedMusicVideos 	videodb://recentlyaddedmusicvideos/

Ohne es zu nutzen vermute ich mal stark das Bumblebee den Code korrigieren müsste und dann kommen deine Kategorien auch die du unter videos/musikvideos/ siehst.
Also Interpret, Genre oder was auch immer..

Da brauchst du ein Skinupdate und musst nichts löschen - es ist einfach der Pfad nicht korrekt der im Skin hinterlegt ist in der Auswahl und dann kommt auch nichts im Widget.

Grüße

Zitat von ulo

Es wird ja an dieser Stelle wohl ein DB-Link gesetzt (library://music/musicvideos). Scheinbar führt der Eintrag ins Nichts.

Da Musikvideos zu videos gehört müsste das auch library://video/musicvideos sein.
Und die dazugehörenden "DB Pfade, bzw. Defaultnodes von Kodi die er anleget wenn eine Quelle vorhanden ist".

http://kodi.wiki/view/Opening_Windows_and_Dialogs#Videos

Grüße

Das wikki ist super wichtig (auch wenns nicht immer stimmt).
An die Tags muss man sich genau halten da ein Skin ja nur eine Oberfläche von Bedienelementen Interner Funktionen des Programmes ist.

Das braucht schon eine Weile bei der Menge an verschiedenen Elementen bis man die Blind zuordnen kann;).

Grüße

Hey,

Du solltest dir immer zu jedem Tag den du änderst das wikki ansehen.
Ausnahmslos jeder XML Tag oder besser gesagt Conditions und ListItems sind dort genau vorgegeben.
Du bist daran gebunden, mit dem Rest kann Kodi nichts anfangen.

<item>
	<label>$LOCALIZE[40010]</label>
	<onclick condition="Library.HasContent(movies)">ActivateWindow(10025,special://profile/playlists/video/KIDS_MOVIES.xsp,return)</onclick>
	<onclick condition="!Library.HasContent(movies)">ActivateWindow(Videos,sources://video/,return)</onclick>
	<property name="menu_id">$NUMBER[50001]</property>
	<thumb>icons/sidemenu/tinker_icon2.png</thumb>
	<property name="id">moviesKids</property>
	<visible>!Skin.HasSetting(HomeMenuNoMovieButton)</visible>
</item>

z.B. <visible>!Skin.HasSetting(HomeMenuNoMovieButton)</visible> bezieht sich auf das Setting im Skin - da sind Ausnahmsweise eigene "Namen" möglich. heißt aber auch wenn Filme deaktivierst kommt der auch nicht mehr.
oder   <onclick condition="Library.HasContent(movies)">ActivateWindow(10025,special://profile/playlists/video/KIDS_MOVIES.xsp,return)</onclick>ist sicher unnötig - du fragst ab ob deine DB Filme hat und öffnest die Playliste. Wenn nicht Videoquellen.

Das wird kaum vorkommen wenns ne Playliste aus der DB ist, kann also raus zu
<onclick>ActivateWindow(10025,special://profile/playlists/video/KIDS_MOVIES.xsp,return)</onclick>
In deinem Fall wirds daran liegen:

<visible>String.IsEqual(Container(9000).ListItem.Property(id),moviesKids)</visible> stimmt schon mal, hast ja im Menüpunkt <property name="id">moviesKids</property> eingetragen.
Library.HasContent(moviesKids) gibts aber nicht

http://kodi.wiki/view/Skinning_Manual#Library

in deinem fall kann das ohne sein (du hast ja sicher eine DB wenns ne Playliste ist)

<include content="WidgetListPoster">
							<param name="content_path" value="special://profile/playlists/video/inprogress_kids_movies.xsp"/>
							<param name="widget_header" value="$LOCALIZE[31010]"/>
							<param name="widget_target" value="videos"/>
							<param name="list_id" value="51000"/>
						</include>

Das könnte gehen, muss aber nicht, ich kenn den code nicht, und seh auch nicht ob das parameter list_id so geändert wurde das es nur einmal vorkommt in der Home.xml und weiß auch nicht genau wie
in dem Skin die Navigation aufgebaut ist.
Versuchs erst mal damit.

Grüße

Zitat von buhtz

Also im Grunde wäre das ein Bug in KODI. Aber ich weiß schon wie die Kodi-core-devs auf so einen Report reagieren würden.
Technisch ist es doch keine große Sache zwei Zeitstempel (der NFO's) abzugleichen, um zu wissen, ob die NFO verändert wurde und sie dann ggf. komplett neu einzulesen.

das ist kein Bug und extra gewollt. Kodi sucht bei einem DB Update nur nach neuen Mediendateien per Fast Hash Algorithmus und fügt diese in deine Datenbank
ein. Genauso bei einer Bereinigung.

Stell dir vor ich seh Film A, und aktualisiere danach meine Datenbank. Dann wäre auch der Watched status wieder Null, Bookmarks wären weg, usw.
Und wer exportiert denn schon täglich alle NFO´s bzw. hält die Konform mit der Datenbank.
Ich nicht, und sicher auch etliche andere.

Das wird auch extra so gemacht damit die Aktualisierung schneller geht - es sind ja dann tausende NFO Dateien die zusätzlich geprüft werden müssten.
Oder anders gesehen mehr Dateiendungen im Fast Hash Algorithmus von Kodi.

Wenn man viele Änderungen vornimmt hilft meist nichts andere als eine neue DB oder die geänderten Filme kurz in ein Temporäres Verzeichnis verschieben, DB bereinigen
und wieder zurückschieben und aktualisieren.
So mach ich es jedenfalls.

Grüße

Zitat von BJ1

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