Das erste dürfte eher
pvrosdguide
sein.. zeigt ja nur einen Sender was gerade und demnächst läuft.
Beim zweiten Bild würde ichs eher mit
tvguide
versuchen. Wenn es aus dem Menü heraus so kommt kanns eigentlich nicht der Dialog pvrguideinfo sein sonder müsste eher das
MyPVRGuide.xml fenster sein.
DialogPVRInfo (pvrguideinfo, radioguidinfo) ist das Äquifalent zu DialogVideoinfo denk ich.
Grüße
auf meiner Fernbedienung mehr frei habe
Na dann macht das ja halbwegs Sinn;).. Für mich war die Frage nur ob nicht soweiso alle eher über die OSD Liste gehen - da gibts ja quasi dasselbe.
Aber wenn man natürlich keine Taste mehr für hat ist das natürlich so geschickter 
.
Dann erwische ich mich an und ab bei der direkten Zifferneingabe - solange die einstellig sind - und eben beim Zappen mit hoch/runter.
Das wird glaub ich bequemer und eher "Receivermäßig" wenn die nächste version auf das Enter und dem unpassendem Nummerdialog verzichtet.
Aber Danke für die Infos ihr zwei 
Bisher war für mich das immer irgendwie alles "zu doppelt" mit einem Dialog der dasselbe kann wie das Fenster.
Wobei man dann doch überlegen müsste auch den Dialog mit verschiedenen layouts zu haben (falls das ginge).
Grüße
Die meine ich ja
OSD-Kanalliste
Ansich, nutzt man das start des letzten programmes/immer dasselbe programm, dann wäre das MyTVChannels Fenster quasi überflüssig.
Deswegen die Frage für was es das Fenster überhaupt gibt und was der gemeine Kodi Nutzer damit macht - damit ich mir vorstellen kann wie es aussehen könnte
muss man sich ja in Nutzer reinversetzen (wenn man selbst keiner ist).
Spartanisch ist eben auch der Tatsache geschuldet das man als Default bei allem Nutzbar sein soll/will/muss.
Eckige Logos, Tranzparente, Rechteckige, so ganz ohne.. IPTV ohne "Aufnahmen in dem Sinn", quasi alles von Info "voll" bis "nix".
Das macht es schon bei Musik schwer und hier noch mehr.. Da bleibt halt nicht viel als ne schnöde Liste;)..
Die Panels mit Logos im 1:1 Icon Verhältnis z.B. ist ja schon schwierig. Bei Tranzparenten in Blau mit Thema blau fast unbrauchbar.
Text geht halt immer..
Grüße
Mal eine Blöde Frage eines nicht PVR Nutzers.
Für was ist die MyTVChannels überhaupt gut? Würde ich unseren Receiver "Nachbilden", nimmt man doch eher das Setting letzter Kanal abspielen oder Fixer Startkanal
(gibts ja glaub ich wenn mich nicht alles täscht). Danach "Navigiert man doch eher mittels Zahleneingabe, Zappen oder diesem Channellist Dialog oder?
Für was ist dann aber die Liste gut? Zumindest ab Kodi 18 ändern sie ja soweit ich gesehen hab die Nummerneingabe ohne das der Nummerdialog kommt (sondern nur eine
Anzeige aus dem Skin) - falls das vielen zu Umständlich war.
So rein generell versteh ich nicht so ganz den Sinn des ganzen Fensters überhaupt. Alles an Einstellungen wie Umbenennen, Löschen, Logo zuweise gibts ja in diesem Einstellen Dialog.
Timer und EPG sind ja auch woanders.
Dann bleibt ja nur noch vom Home aus zu Live-TV wechseln und einmal nen Kanal Starten oder?
Da würde ich ja lieber "erstmal irgendwas" automatisch laufen lassen und dann mit der OSD Liste, Zahlen oder Zappen Arbeiten.
Da gibts ja quasi dasselbe in Grün + noch das Bild dazu wenn ich während der Listennavigation schnell sehen will was das eigentlich genau ist was da kommt.
Wahrscheinlich ist das deshalb so spartanisch im Original.
Grüße
Cool, da ist einer gekränkt weil man sagt was toll wäre. Und das von einem der sicherlich von Gestaltung mehr Ahnung hat. Und da bin ich mir sicher!
Ich will ja kein Öl ins Feuer gießen - gehört auch nicht zum Thema, aber wenn man schon Ahnung von Gestaltung hat, sollte man auch wissen das man die Funktion und Ablauf seines "Produktes"
auch kennen sollte wenn man hier "meint etwas besser zu wissen".
Da driften oft die Ansprüche auseinander wenn Designer mit Scribbeln daherkommen und nach dem Motto "so solls sein" aber gar nicht bedenken das man hier von einer GUI spricht
die in ihren Möglichkeiten eingeschränkt ist.
Genauso wie ein Architekt etwas Ahnung von Statik haben sollte ob sein Entwurf nicht gleich zusammenbricht, sollte man sich schon in Kodi erst mal mit der Funktion und den Möglichkeiten
des Skinengines befassen, und nicht Dinge vorschlagen die gar nicht Möglich sind oder nur Eingeschränkt.
Eine Trennung ist einfach nicht Möglich in Kodi. Und solange kein "Gestalter" sich die Mühe machen will sich Coding anzueignen, muss man wohl damit leben das die die es tun andere Prioritäten haben als
man selbst. Man sollte eher froh sein das Jemand der Arbeit reinsteckt überhaupt Dinge verwirklicht die ihm selbst unwichtig sind.
Schlussendlich bindet er sich damit die Codepflege und nen eigenen Skin ans Bein der Langsamer ist als er sein müsste (Skinning bedingt ist das einfach so).
Leider vergißt man immer häufiger das das alles Hobby ist. Skinner sind (vermute ich zumindest) immer (oder oft), Leute die sonst weder etwas mit Code noch Grafiken zu tun haben.
Das wird alles mit der Try and Error Methode hart in der Freizeit erarbeitet. Wer sucht sich denn ein Hobby aus das man Tag ein Tag aus beim Arbeiten schon macht?
Keiner.. Das sind alles weiß Gott keine Programmierer oder Designfachleute die schon 30 UI´s entwickelt haben, inklusive Menüführung, Navigation und Verzahlnung von über 70 "Anzeigen".
Das Motto "Respekt wers selber macht" kommt leider immer schnell zu Kurz und all zu oft wird Professionaltät erwartet die gar nicht Notwendig (Möglich) ist.
Meiner Meinung nach darf man nicht Vergessen das man hier keine Anzeige bekommt wie eines Profigerätes (TV z.B.) bei dem Entwickler, Techniker und Designer die Anzeige und den Code aufeinander
Abstimmen - und man auch mal etwas "umprogrammiert" damit die Software zur Anzeige passt.
Hier Versucht man als Hobby die vorhandene Tecknik anzuzeigen. Dazu muss man jedem auch mal zugestehen das man aus Lust und Laune sich gerade einfach gern mit nem Rating auseinandersetzt.
Auch wenns dem einen oder anderen Egal sein wird.
Von mir großes Lob das überhaupt mal einer was macht, und nicht vergessen, es ist der zweite Versuch und nicht der zehnte 
.
Und dabei folgt man immer dem Prinzip "learning by doing".
Grüße
Eigentlich immer außer halt im Provider. Wobei aber der parameter Mist hier schon Ausufert für meinen Geschmack;).. Da ist ja mehr definiert als tatsächlich drin ist.
Grüße
Du meinst im Shutdown? DialogButton.xml oder so ähnlich? da gehen mein ich auch mehrere..
Mein Content provider Porblem ist im prinzip dasselbe wie deins:
Ich muss es so einfügen weil es in einem Custom Window ist:
<content target="video">$VAR[Content-Similar]</content>
<onclick>Dialog.Close(1141)</onclick>
<onclick condition="String.IsEqual(ListItem.DBType,tvshow)">ActivateWindow(Videos,"videodb://tvshows/titles/$INFO[ListItem.DBID]/")</onclick>
<onclick condition="String.IsEqual(ListItem.DBType,movie)">PlayMedia($ESCINFO[ListItem.Path])</onclick>Damit der Click vom Core nicht dazu führt das er alles im Hintergrund abspielt weil der interne ja nicht alle Dialoge davor schließt.
Auch nicht zu Ende gedacht und fällt nur auf wenns in keinem Window ist sondern nem Dialog (wie eine Sidebar als Extra Datei).
Und wie bei dir: Ein PlayMedia und ich muss auch serien öffnen einfügen sonst bekomme ich da nichts außer den Play Error im Log.
Aber Naja, wenn mans weiß ist es ja ne Kleinigkeit und weniger schlimm als bei dir..
Grüße
Eine Schleife wird so lange wiederholt, wie eine Condition wahr ist. If-Then-Else ist eine Verzweigung in Abhängigkeit einer Condition und keine Schleife . Je nach Condition ist entweder der eine Teil oder eben der andere Teil 'toter Code'. Könnte man fast vergleichen mit <visible condition='false'>. Code ist zwar da, wird aber nicht ausgeführt.
Siehst, deswegen lass ich die Finger davon . Verzweigung, Schleife.. Alles dasselbe für Unsereins bei dem du wahrscheinlich Migräne von bekommst.
Grüße
Das Dumme bei den (TV-)Widgets im Estuary ist jetzt, dass diese überhaupt keinen Click definiert haben und damit automatisch intern 'playmedia' ausgelöst wird. Leider greift auch ein <click>Default</click> nicht, da nicht implementiert (das könnte ja der playmedia sein). Achja, <click>playmedia</click> geht auch nicht. Fazit: Leider nicht zuende gedacht.
Das meinte ich ja mit "es fehlt was im provider".. Oder du Fuchs hast dich einfach durch ne Lücke gezwängt und den Provider für was verwendet an das noch keiner dachte 
.
Sonst außer deins und das Newscenter sind es ja eigentlich immer irgendwelche DB Filter wie Becaus you watched oder der Library Provider..
Da hast dich wohl reingeschummelt in was das nie für mehr Gedacht war.
Aber interessanterweise kannst oder konntest früher, schon länger nicht versucht, in einigen content die abspielbra waren jeden "mist" in target schreiben, es ging trotzdem irgendwie und wurde abgespielt.
Wäre vielleicht sogar ein leichtes wenn sie das mal richten - Ich muss in meinen Dialogen auch mit mehreren clicks für Serien und Filme extra arbeiten, nur weil ich beim Überschreiben auch jede Möglichkeit angeben muss.
Da fehlt ein Dialog.close(all) als erster click, was dazu führt das Filme im Hintergrund laufen..
Übrigens der Unterschied zwischen <include condition> und <visible condition> ist mir schon klar .
Dachte ich mir fast .. mich hatte nur das "Includes werden doch wirklich nur inkludiert (und damit der 'Quelltext' vergrößert) , wenn die entsprechende Condition auch greift (wahr ist)" irritiert.
Im Engine sagen wir zwar zu beidem condition.
Eine Programmschleife ist für mich als Nichtprogrammierer eher so eine If-Then-Else Geschichte in der man quasi "Toten Code" hat der nach dem Vergleich nichts mehr macht.
Was dann nur auf <include condition> zutrifft.
Grüße
Stell' Dir eine Programmschleife vor, die z.B. 1000x loopt. Da wird 1000x eine Condition geprüft...
Includes werden doch wirklich nur inkludiert (und damit der 'Quelltext' vergrößert) , wenn die entsprechende Condition auch greift (wahr ist).
Naja, leider eben nicht so ganz - ich bin ja nicht so der Erlärbär, dazu schweife ich immer zu sehr ab, aber ich versuch mal:
Includes ohne condition, Angezeigt nur durch visibles wie im Estuary mit
<visible>$PARAM[visible]</visible>
werden immer geladen nur nicht angezeigt. Das ist ein großer Unterschied.
Ein
<include condition="Bin ich ein Briefkasten">Briefkasteninclude</include>wird in der Tat nur geladen wenn sie zutrifft.
Ein
<include>Briefkasteninclude</include>mit einem visible im Code <visible>Bin ich ein Briefkasten?</visible> wird immer geladen, nur nie angezeigt wenn es keiner ist.
Geh ich nun vom Home in Filme, und wieder zurück, ist die Anzeige des Inhaltes nur "so schnell" da weil die ganzen includes im Speicher bleiben.
Immer der komplette Inhalt des aktuellen Fensters und das PreviouseWindow bleiben in Loader - das ist auch der Grund warum bei komplexen Skins beim ersten öffnen von Filme paar Sekunden warten musst während es danach schneller ist. Erst ab dem "dritten Fenster", würde ich jetzt von Filme zu Einstellungen wechseln fallen die Includes die nur im Home verwendet wurden aus dem Speicher wenn sie nicht auch in Filme eingesetzt wurden.
Dies Menge an include beeinflussen die Geschwindkeit enorm - würde man in einem MQ mal 80% der Views rauswerfen und beide versionen auf einem Pi testen, würde man nen deutlichen Unterschied merken. Da ist es genau dasselbe - jede view mit ihrem visible mit geladen in der Mynav - nicht nur die gerade aktive..
Und das ist eben der Knackpunkt:
Der Estuary "Bügelt" schon mit seinem Aufbau eine "Unzulänglichkeit", oder keine Ahnung wie man sowas nennen soll, aus:
Ein
<include condition="Bin ich ein Briefkasten">Briefkasteninclude</include>wird ja nur geladen wenn es beim Laden zutrifft.
Sprich, die Widgetgruppe Filme, ist ja sichtbar wenn
<visible>String.IsEqual(Container(9000).ListItem.Property(id),movies)</visible>zutrifft. Die würde mit einem include condition="<visible>String.IsEqual(Container(9000).ListItem.Property(id),movies)</visible>" nur kommen wenn beim laden der Menüpunkt Filme fokussiert ist. Nur dann und auch wirklich nur dann.
Ist es ein anderer und scrolle ich zu Filme kommt gar nichts außer man würde reloaden und den Focus dabei behalten.
Würde man jetzt alle Propertys in irgendwelche "Monstermusterwidgets" Anhand des Focus bestimmen, ohne alle Widgets extra zu machen.
Also Widget1 bleibt stehen und der Inhalt ändert sich durch das Scrollen:
ListItem.Property(id) macht ja nichts anders - im Menücontent ist ein property ID. Da könnte ich auch den content als Property reinschreiben und denselben Container
für Movies und Serien nehmen...
Da Kodi aber nicht schnell genug dafür ist, kannst dann beim Scrollen bis zu einer Minute warten bis der Inhalt wechselt und das Widget aus dem vorherigen Container
wäre solange noch als Inhalt sichtbar.
Das gleicht man aus indem man alle Widgets nicht einmal sondern für jeden Menüpunkt extra drin hat und jeweils nur eins Anzeigt das dem Property ID entspricht.
Über Sinn und Unsinn kann man jetzt streiten, ich find diesen Aufbau für ein Konfigurierbares Menü wiedersinnig:
Die 30 Widgets lass ich dann Anzeigen mit einem visible "condition irgendwas" was dann true ist. Die anderen 570 schwirren halt irgendwo im Nirvana herum.
Das kann ja nicht Sinn und Zweck sein, zumindest für mich nicht.
Aber das war ja eigentlich auch nicht der Grundgedanke, wir sind ja vom eigentlichen Thema abgekommen:
Dein richtiger Einwand, ein Template das an einer Stelle Abweicht neu zu machen wäre Pfusch, ist ja richtig.
Deswegen die Suche nach dem Grund:
Fängt man da bei Null an muss man sich ja nicht als erstes Fragen warum klappt der conditional Click von dir nicht, sondern warum klappen die Kodi internen clicks in anderen contents?
Egal ob nun videodb:\\movies\titles oder plugin://service.library.data.provider?type=randommovies&reload=$INFO[Window.Property(randommovies)] oder alle videoaddons in einer Liste,
der click geht von selber, ohne einen selbst im Skincode zu haben. Ob der nun vom Target irgendwie vom Core ermittelt wird, keine Ahnung.
Darum war die Frage: wenn man nach der Übergabe von plugin://mein.persoenliches.plugin?action=machdies&wasgenau=$INFO[Window.Property(briefkasten)] man keinen Einfluss mehr darauf hat
und das Kodi danach Regeln muss, das dann doch was fehlt oder?
Wenn das action=machdies von dir nicht mitgegeben werden kann in Form eines RunScript was du brauchst fehlt ja die Funkion im provider generell...
Also was in der Art:
Einen Click angeben oder den internen von Kodi nutzen wenn es einen hat.
<content target="video" defaultclick"true">plugin://service.library.data.provider?type=randommovies&reload=$INFO[Window.Property(randommovies)]</content>
<content target="video" defaultclick"false" click="machdies">plugin://mein.persoenliches.plugin]</content>Denn so kann man die Contentgeschichten ja wirklich nur für Dinge verwenden die Funktionieren.
Der Vorteil von Infolabels und Artworks Allgemeingültig zu Nutzen um im selben Layout verschiedene Inhalte Abzubilden wird ja ad absurdum geführt wenn ich danach prüfen muss in welchem
das Ausführen geht und alle bei denen nicht, dann einzeln Einbaue um so eine Funktion des clicks Nachzubilden.
Aber vielleicht bin ich ja auf dem Holzweg. Ändern kann man ja eh nichts dran.
Wenigstens klappts jetzt bei dir, das ist ja schon mal was;)..
Grüße
Alles, was im Aufruf nach dem "?" kommt, sind Parameter, mit denen Du ein Addon/whatever steuern kannst.
eigentlich alles;)..
Abseits vom menüscript mit Templates läuft das ja so:
Hat man ein wählbares Widget, setzt man den content in einen string der im skinsetting landet.
Man baut also settings dafür die den ganzen content in den string schreiben:
Skin.SetString(Widget1,plugin://service.library.data.provider?type=randommovies&reload=$INFO[Window(Home).Property(randommovies)])
Das reload kommt vom script und sort denk ich dafür das der Service das aktualisiert.. Die Zeile bekomme ich so vorgegeben vom Addon während der click von selber geht, ohne ein Runscript oder irgendwas drin.
Oder für einen anderen inhalt dann
Skin.SetString(Widget1,plugin://mein.persoenliches.plugin?action=machdies&wasgenau=$INFO[Window.Property(briefkasten)])
Danach dann kann ich dann vereinfacht gesagt den content im Widget 1 mit
<content>$INFO[Skin.string(Widget1)]</content>
darstellen und muss nur die die sich im layout unterscheiden mit irgendwas auch immer getrennt im code darstellen - wie im Estuary Poster, Music oder aber ein Addon bei den der click nicht geht.
Heißt also wäre jetzt Serien oder Filme drin, die beide als Poster dargestellt werden sollen/können, kann ich das in einem include schaffen, was das im Estuary refresh so aussieht:
<include content="WidgetListPoster" condition="String.IsEqual(Skin.String(CustomHome1WidgetLayout1),filme) | String.IsEqual(Skin.String(CustomHome1WidgetLayout1),serien)">
<param name="content_path" value="$INFO[Skin.String(CustomHome1WidgetPath1)]"/>
<param name="widget_header" value="$INFO[Skin.String(CustomHome1WidgetHeader1)]"/>
<param name="widget_target" value="videos"/>
<param name="list_id" value="6022"/>
</include>Das wird natürlcih noch komplizierter mit traget, limit und dem ganzen Rest an sortierungen.. Also eigentlich schon schlimm genug;)
würde jetzt der click gehen in einem Addon das einen content zur verfügung stellt, muss ich nur noch eins der vorhandenen Layouts finden das passt, z.B. episoden das eh schon da ist und das skininterne Widgetlayout erweitern und beim addon gto sagen setz den content in einen string und sag dabei zusätzlich noch widgetlayout = gto
<include content="WidgetListEpisodes" condition="String.IsEqual(Skin.String(CustomHome1WidgetLayout1),episoden) | String.IsEqual(Skin.String(CustomHome1WidgetLayout1),gto)">
<param name="content_path" value="$INFO[Skin.String(CustomHome1WidgetPath1)]"/>
<param name="widget_header" value="$INFO[Skin.String(CustomHome1WidgetHeader1)]"/>
<param name="widget_target" value="videos"/>
<param name="list_id" value="6020"/>
</include>Dann sorgt das String.IsEqual(Skin.String(CustomHome1WidgetLayout1),gto) dazu das es angezeigt wird wenn das addon der content wäre, während im Skin.String(CustomHome1WidgetPath1)
der content Skin.SetString(Widget1,plugin://mein.persoenliches.plugin?action=machdies&wasgenau=$INFO[Window.Property(briefkasten)]) stehen würde.
Wenn, ja wenn der click gehen würde. da er das nicht tut brauch ich dein extra include in jedem konfigurierbarem menüpunkt.
Du hast ja jetzt im Estuary als Beispiel einfach in der Widgetgruppe fürs Live-TV dein Addon Hardcoded als Include drin, richtig?
Jetzt stell dir vor der bumblebee macht das auch, der hat aber meinetwegen 6 Menüpunkte die Live-TV sein können. Er ruft also das include als conditional 6 mal in jeder Gruppe einmal auf.
Egal ob der user das nun überhaupt wählt oder er Live-TV im menü hat. Jedesmal beim aufrufen der Home werden alle 6 includes aufgelöst von Kodi und entsprechend dargestellt oder nicht.
Selbst wenn ichs nie verwende wird bei jedem Laden das geprüft.
Da muss man sich schon gut Überlegen ob man das Addon einbaut, Da kommt man schnell auf 15 Container includes pro Menüpunkt für 3 Widgets bis man alle Möglichkeiten drin hat für jedes
mögliche Widget. Machst noch Wetter oder sonst was in jedem dazu wird nochmal mehr.
Deswegen fehlt für mich einfach der "automatische click" ohne was zu tun. Und nicht jeden einzelnen Briefkasten einzeln einzubauen bis ich ein eigenes Postverteilungszentrum bin;)..
Grüße
Und das heißt als content hat man drauf keinen Einfluss und kodi macht das? dann fehlt doch was in dem content provider denkt man zumindest wenn man keine Ahnung davon hat;)..
Ansich hat dann ja ein "Mischen im Sinn von ein Container und der user wählt den Inhalt, während der Skinner dann im selben Layout verschiedene contents anbietet" außerhalb von Datenbankabfragen
wo der click geht überhaupt keinen Mehrwert mehr außer das dir die "alten liste" sparst mit item id="1" usw..
Aber das ist ja eigentlich auch nur einmal schreiben und eine Nummer suchen und ersetzen.
Das mischen hat ja den sinn das ich im selben Container nun sagen kann der user kann wählen zwischen meinetwegen
<content target="video">plugin://service.library.data.provider?type=randommovies&reload=$INFO[Window.Property(randommovies)]</content>
<content target="video">plugin://service.library.data.provider?type=recentmovies&reload=$INFO[Window.Property(recentmovies)]</content>
und man nur einen Container braucht was die Menge extrem reduziert.
Selbst ohne Parameter nimmt man mal an ich setz den content als string oder zur Auswahl mit einer variablen 1= randommovies, 2= recent, steh ich vorm selben Problem wenn
ich nen extra click brauch, das wieder entweder deiner geh oder die anderen.
Und grade diese Extras lassen dann alles immer ausufern in Widgets und dem Home speziell.
Aber damit muss man wohl leben - den provider gibts ja nun seit einigen versionen und wenn es bisher keinen störte wird da wohl nix geändert.
Wird eher schlimmer wenns dumm läuft - ab 18 kannst mehrere contents in eine Liste packen - wer weiß was da dann noch alles schief geht;).
Grüße
Meinst Du sowas (im Skin)?
eher im addon dachte ich.
Wenn Kodi einen Provider anbietet, in dem ich ja quasi alles irgendwie unterbringen kann, wie tdoe der da Bundesliga Ergebnisse drin hatte, dann braucht doch diese Funktion in Kodi auch etwas
wo man im Addon sagen kann was beim click passieren soll - hängt das am target wie video und die knobeln das anhand von dem aus ob nun open in videos wenns ne serie ist oder play bei einem Film, dann fehlt
doch generell schon was in der Providerfunktion oder sie Erlaubt an einem Ende mehr als am anderen (dem click) dann Möglich ist.
Es bringt ja herzlich wenig Bundesligaergebnisse in einen Content zu packen wenn man schlussendlich extra container dafür braucht um nen click zu bekommen.
Deswegen die Frage ob das der Core selber macht in anderen Content wie dem library Service Data Provider oder ob da der click direkt vom Addon kommt.
Ich hab da ja keine Ahnung von, aber als Skinner will man natürlich den content provider einfach als content angeben und geht davon aus der click kommt vom content selbst.
Aber das ganze ist eh etwas buggy mittlerweile - teilweise gehen auch die clicks mit DB contents nicht mehr wenn die listen im falschen "Fenster" sind.
Im videofenster oder der Videoinfo z.B. oder einem Custom Window gehen die teilweise nicht mal mehr mit DB content alleine.
Da fehlt hier mal ein close (wenns Dialoge sind), und da mal die ganze funktion (weil man schon in videos ist)..
Grüße
Mit der Einführung der String- und Integer-Conditions hätte man gleich Nägel mit Köpfen machen können und nicht nur Infolabels, sondern auch Parameter und Variablen mit- und gegeneinander vergleichen können. Chance verpasst.
Abseits davon mal ne andere Dumme Frage - kann man denn nicht den click schon übergeben im addon damit der content keinen braucht oder regelt das nur der core über das target?
Deins ist ja sicher nicht das einzige was in der Konsteallation Probleme macht - das Infoding mit der Bundesliga damals war ja genauso betroffen und eigentlich alles das extra clicks brauchte.
Dann fehlt doch generell was in Kodi das einem Addon die Möglichkeit gibt den click mitzuteilen.
Grüße
Alles klar.. Das grün und so was hatte ich gemacht - Rest muss man dann schauen wie das mit den infos werden soll und der iconhinterlegung.
Grüße
Als Programmierer rollen sich die Fußnägel, Code zu doppeln, der sich in nur einer Zeile unterscheidet. Wie sualfred schon sagte: Damit ist der Sinn von einem Template zu haben wieder weg. Aber wenns geht?
Da muss man aber durch im Skinengine . Und wenn genau hinsiehst rollen sich auch deine Nägel auf ein Template zu verwenden das dann Sortby, Limit und diverse andere Dinge ins leere laufen läßt weil es das nicht gibt, oder eine Variable Texture zu Overlays mitläuft die soweiso immer Empty ist im Addon. Und ob deine Addon Thumbs (sind die nicht square) mit keep in der texture
<width>245</width>
<height>200</height>jetzt so unbedingt gut werden..
Hand und Fuß hat das halt nur wenn man alles auseinander trennt wie Sualfred es macht. Und selbst da kommst an einen Punkt wo man sich entscheiden muss ab wann man mit den "Fehlern" nicht mehr leben will.
Nehm ich jetzt ne Textbox und leb damit das Einzeiler eben nicht mittig sind oder ein Label hab aber nur eine Zeile. Im Skinengine ist vieles immer pfusch weil sogut wie alles doch irgendwie nicht gleich ist.
Egal ob mit oder ohne Template.
Ich geh eher den Weg das Code nur dort steht wo er auch etwas macht, dann lieber mehr Templates oder mehr Code die eins richtig machen als wenig code (oder Templates) die Codeteile mitlaufen lassen die unnütz sind oder
nachträglich mit conditions ausgeblendet werden. Global wird mir das sonst zu kompliziert mit include im include im Parametetrierten include im include.. Nur um 80 zeilen code zu sparen.
Davon mal abgesehen wird Kodi auch nicht schneller wenn man das Übertreibt, als einfach eins mehr mit klarem visible zu verwenden als Mörder komplizierte Templates zu bauen die jedes mal aufgelöst werden müssen.
Mir kommt es eh so vor als wären Parameter langsamer, aber das weiß sualfred als "Parameter Includierungs Ebenenkönig" sicher besser was er da tut .
Aber ich hab auch leicht reden weil unser Skin so gut wie nichts macht weil wir Kodi nur als aufgehübschten Player nutzen ohne Widgets, Addons oder sonstiges .
Grüße
Da hast natürlich recht;).. Nur das Template ist eben auch nicht für solche Dinge gedacht gewesen da es der Ersteller nicht vorsah.
Ich kopier es da lieber als irgendwo drumherum zu kommen und zu hoffen das es dann schon nach der dritten Ebene alles abdeckt .
Da kommt ja meistens dann 4 Wochen später in Kombination bei irgendwas wieder was falsches raus und irgendwann hast dann 5 wie du.
Aber parameter ist auch gar nix für mich. Ich nutz die fast gar nicht weil vieles auch super ohne geht und teils nur ne andere Schreibweise fürs selbe ist.
Ob ich nun nen Hintergrund includier und breite und höhe so reinschreib oder als Parameter, macht es für mich nur Unleserlicher.
In dem Fall seh ichs ein das man die braucht in diesem layout der Widgets.
Wird Ansichtssache sein bis wann man ein Template verkomplizieren statts für andere Dinge neue zu verwenden wenn möglich.
Es wurde ja auch schon die Entscheidung getroffen ein Widgetchannellist Einzubauen weil es zu stark von anderen abweicht.
Das ist ja so eine Kodi krankheit - 90% sind gleich aber dann doch irgendwie immer etwas anders - das kann einen schon Wahnsinnig machen machmal
Grüße
Das meinte ich damals im Flex das ich nen eigenen Comtainer für das Widget brauch weil der click die anderen clicks verdrängt..
Ich hab dann einen eigenen Container dafür verwendet weil mir das zu blöd war anders.
Damals ging es nur wenn ich alle clicks definiere - da ich aber in den strings für die Widgets keine Info hab in was für nem Fenster falls es was anderes ist,
hab ich extra includes verwendet.
Du rufst ja eh ein include auf.
<include content="WidgetListChannels" condition="System.HasPVRAddon + System.HasAddon(plugin.service.gto)">
Kopier es doch einfach und nenn es anders und verwende das - so ist es wenigstens Bombensicher.
Grüße
Genau.. Muss ja auch - Basissprache in deinen PO´s ist immer das Fallback:
Du Übersetzte ja
msgctxt "#1"
msgid "Pictures"
msgstr "Bilder"
Pictures und nicht 1.. siehst auch in Knightly.. Da bleibt auch mal ein Text Englisch wenn die betreffende Nummer noch nicht in DE vorhanden ist oder der Englische Text geändert wurde.
Sonst könnte man ja keine schon vorhandenen Nummern korrigieren in der Ausgangssprache.
Das System mag jetzt nicht perfekt sein, geht aber auch nicht besser: Würde man alle Sprachen Vorschreiben was wäre die Konsequenz?
Ich entwickel einen Skin von Null auf selbst, kann ihn aber nur für einen Franzosen Übersetzen wenn ich nen Vietnamnesen find der ihn auch will?
Und wenn dann jeder Anfängt das zu faken in dem man in 15 Sprachen englisch kopiert hat es ja denselben Effeckt.
Das System ist ja aufs mitmachen ausgelegt: Basissprache Englisch einfügen, im orgforum veröffentlichen, und wenn ein user aus Vietnam das Ding super findet, kann er sich einbringen
und im Projekt Helfen mit der Übersetzung.
Der ganze Aufbau des Übersetzens in Kodi ist aber soweiso nicht wirklich gut so. Es ist zwar einfach aufgebaut, aber ob das immer gut so ist sei mal dahingestellt.
Grüße
Hat Martijn am Schluss ja auch geschlossen mit der Aussage
ja schon.. nur in der Mitte der Diskussion mit den fixen was nun passiert wegen der Unterschiedlichen Datums und Stundenformat, hab ich den Faden verloren ob es nun weiterhin als Fallback zu "Englisch ohne was" zurückfällt wie es bei Addons üblich ist die oft nicht mal alle haben.
Bei denen ging es ja eher ums richtige Benennen - deswegen denk ich im Endeffeckt landet man mit nur Englisch beim selben wenn man nur das reinlegt.
Bei den kodi texten wird das ja auch reichen - so viele Sätze mit Grammtik die sich Unterschiedet gibts ja nun nicht wirklich und die meisten Zahlenformate
und dergleichen hängen ja mittlerweile eh am Core.
Grüße
