Gibts da ein repo @SLiX mit einem repraesentativen Beispiel von membrane?
@voodoo44
Dein merge ist etwas komisch: Der erste commit hat keinerlei Aenderungen. Da waere squashen (zusammenfuegen zu einem "sauberen" commit) for dem mergen angesagt, damit die master commit history moeglich sauber und klar bleibt.
Ich wuerde auch sagen PR's sind intern nicht wirklich noetig. Wir muessen uns sowieso absprechen bezueglich den Interaktionen zwischen den einzelnen Modulen und wenn zwei (oder mehr) am selben arbeiten umso mehr. Einfach wie teufel geschrieben hat nur funktionale commits in den master machen. Kleinere Entwicklungsschritte als commits in lokalen oder separaten branches festhalten und dann squash-mergen in den master. So wuerde ich es angehen.
Ich denke was wir jetzt machen/diskutieren muessen ist: Klassen mit ihrer Funktionalitaet definieren. Ausser jemand hat viel mehr Zeit als alle anderen und haut gleich Mal einen Grossteil des Codes hin kann sonst nicht einfach angefangen werden mit Coden. Vielleicht ist das auch mehr ein Problem von mir, weil ich Kodi Addons nicht gut kenne, und es gibt da einen "Standard". In jedem Fall lohnt es sich meiner Meinung nach so eine Struktur irgendwie festzuhalten. Die wuerde dann natuerlich fortlaufend angepasst/erweitert.
- Ich hätte gerne zu Anfang schon ein schönes Interface. Dafür bräuchten wir jemanden der sich damit auskennt und Kreativ wäre, @membrane wäre das etwas für dich?
Ja der Blingbling Kommentar war reichlich sinnlos. Macht natuerlich voellig Sinn wenn das UI von Anfang an schoen gemacht wird.
- Auswahl der Videos und natürlich dass diese abgespielt werden können. Das ganze sollte schon auf inputstream.mpd angepasst sein (>= Kodi 17).
Als alternative muss natürlich auf den normalen Player runtergegangen werden. (inputstream.mpd / DVDPLayer)
Gibts da irgendwo ein Forum Thread zu diesem neuen InputStream Interface? Ich habe das Repo gesehehen, das dash mit diesem Interface implementiert: https://github.com/mapfau/inputstream.mpd. Was ich aber noch nicht gefunden habe, ist was diese Interface eigentlich ist. Oder kennst du es schon und kannst es in zwei, drei Saetzen erklaeren (fuer Details wird eh Code lesen angesagt sein).
- Die Implementierung von strm-files wäre ebenfalls nciht schlecht, sodass sich das Addon von Anfang an remote füttern lässt (Kore / Yatse / Browser-Addons)
Ich kenne strm-files bisher nur als Moeglichkeit um Addons in die Video Library zu integrieren. Wo kommen da Kore und Co ins Spiel?
Also mir ist alles recht. Wie du sagst merkt man ja beim Programmieren nichts davon wie Kodi spaeter die Module organisiert. Doppelte Arbeit verstehe ich aber nicht ganz: Der Code ist ja derselbe ob das nun ein alleinstehendes Modul oder ein internes ist. Was dazukommt beim alleinstehenden ist das packaging, also addon.xml, setup.py, usw. erstellen. Aber die Arbeit faellt einfach einmal an, ob das nun direkt zu Beginn oder erst spaeter bei Bedarf gemacht, aendert nichts am Aufwand. Oder vergesse ich da was?
Aber irgendwie haengen wir uns an Details auf. Was ja momentan eigentlich wichtig ist, dass wir ein uns ein Framework basteln. Und da muessten wir wohl als erstes Mal Ziele definieren, also was unser Addon in der ersten Version koennen soll. Ich waere dafuer, diese moeglichst tief zu stecken, dafuer klaren und gut erweiterbaren Code zu schreiben. Sobald das dann laeuft, koennen wir immernoch viel Funktionalitaet und Blinbling einbauen. Ansonsten verzetteln wir uns wohl schnell.
Und ja, die Zahl ist ziemlich beeindruckend...
Ins offizielle Repo finde ich auch zwingend. Youtube ist wohl etwas vom ersten was ein neuer Kodi user nutzen will (war bei mir so), und da sind externe Repos nicht gerade naheliegend.
Ich denke es lohnt sich nicht von Anfang an auf ein zweites Modul fuer die Youtube Api zu setzen, Denn dann muss diese library sehr allgemein gehalten sein, also nicht zu sehr auf unsere Beduerfnisse zugeschnitten (sonst nuetzt es eh keinem was). Macht mehr Sinn wenn wir es intern in ein Modul packen und falls wir dann irgendwann das Gefuehl haben, dass es auch alleinstehend Nutzen hat, koennen wir es immernoch ins Repo stellen.
Und wie ich schon geschrieben habe: Die ganz allgemeine Google Api library und oauth library gibts schon, auch schon im offiziellen Repo (veraltet, aber das waere schnell auf den neuesten Stand gebracht), Links:
http://kodi.wiki/view/Add-on:Oauth2client
http://kodi.wiki/view/Add-on:Googleapi
Mir graust es schon vom erstellen des python environments, wenn wir so eine Antiquitaet wie 2.1 benutzen. Gibt es ueberhaupt noch irgend eine Linux-System, dass nicht mindestens 2.6 mitliefert? Da ja auf allen anderen Systemen Kodi python selber mitliefert, sollten wir schon auf 2.6 setzen koennen.
Also die ganze Python env Geschichte wird in diesem Thread recht klar: http://forum.kodi.tv/showthread.php?tid=251555
Also ueberall ausser auf linux wird ein kodi eigenes python verwendet (kodi-python), das ist 2.6. Auf Linux wird das systemeigene python 2 verwendet, wohl ueberall 2.7. Aber ganz ehrlich, ich weiss aus dem Stegreif nicht mal was die Unterschiede von 2.6 zu 2.7 sind, so wichtig wird das nicht sein.
Interessanter ist wie Module gehandhabt werden: Alle nicht internen Module die genutzt werden im Addon (also eingebunden per import) muessen entweder direkt zum Addon hinzugefuegt werden oder im addons.xml als dependency (script.module.*) angegeben werden.
Wegen den Quota habe ich mir auch schon Gedanken gemacht, was da ueberhaupt gespeichert werden kann. Youtube ist ja nicht statisch, also muss jedes Mal aufs neue Daten abgefragt werden. Ausser es gaebe Api Funktionen um abzufragen ob sich seit einem gewissen Zeitpunkt in einem Channel/Playlist/... irgendwas geaendert hat und dieser request muesste wenig Quota kosten. Irgendwie bezweifle ich, dass es sowas gibt. Ansonsten sehe bloss die Moeglichkeit Nutzungsstatistiken zu cachen und dann alle aufs Mal mit Youtube abzugleichen (aber das geht ja anscheinend mit der API gar nicht).
Hast du vor die Youtube API direkt zu implementieren oder googles python libraries (https://pypi.python.org/pypi/google-api-python-client und https://pypi.python.org/pypi/oauth2client) zu nutzen? Ist einerseits ganz gut dokumentiert (z.B. Beispiele https://developers.google.com/youtube/v3/code_samples/python), aber sieht teilweise etwas unnoetig kompliziert aus (weil halt allgemein gehalten fuer alle Google APIs).
Was mir noch Raetsel aufgibt ist das Python environment: Gemaess diesem Wikiartikel (http://kodi.wiki/view/Python_Libraries) scheint Kodi ein eigenes Python 2.6 kompatibles environment zu benutzen um die Addons auszufuehren. Ob das aber noch wirklich aktuell ist? Und in diesem Artikel (http://kodi.wiki/view/Python_Development#Environment_details) toent es wieder so, wie wenn Python von der Plattform abhaengig waere. Kann da jemand genauer Auskunft geben?
Auf alle Faelle sollte mindestens Python 2.6 zur Verfuegung stehen. Darum schlage ich vor dass wir Python 3 code schreiben und __future__ nutzen um diesen 2.6 kompatible zu machen. Python 2 wird zwar noch eine Weile unterstuetzt werden, aber viele Projekte sind schon umgestiegen und so gut wie alle neuen Projekte nutzen 3. Und Python 3 ist mehr pythonisch - ergo schoener, einfacher, besser 
Und zu guter letzt: Ich missbrauche diesen Thread mit diesem Beitrag schon um Fragen zu stellen und Diskussionen zu starten. Ist das ok oder sollte dies wo anders stattfinden?
Ich habe gesehen dass Kodinerds einen IRC channel hat. Koennten wir den ab und zu auch hijacken um uns auszutauschen ? Oder sollen wir uns einen eigenen Channel zutun oder braucht es sowas gar nicht?
Danke fuer die Einladung auf github. Ich habe mir gerade die Freiheit genommen dein Wiki etwas zu aendern. Dabei ist die die Frage aufgetaucht wo Diskussion stattfinden sollten. So wie ich das verstehe ist das Wiki dazu da, zu dokumentieren was geplant ist und woran gerade gearbeitet wird. Wo diskutieren wir Entscheide, die nicht einfach ein Dev allein treffen kann/will? Sobald eine Einigung erzielt wird, gehoert das wohl wieder ins Wiki, aber die Diskussion selber kaum, oder?
EDIT: Habe das noch vor lesen von obigem Post geschrieben.
EDIT2: Der Plan mit Wiki-Dokumentation toent super. Was wir sicher brauchen bevor gecodet wird ist eine klarere Struktur. Vielleicht hat teufel (sorry, fuer schnelleres tippen ist das mein Name fuer dich, Aenderungswuensche koennen angebracht werden ) da schon was im Kopf, aber vom bisher geschriebenen ist die mir noch nicht klar.
Hallo miteinander
Ich mische gerne auch mit. Ich habe im allgemeinen nicht viel Programmiererfahrungen (bin Physikstudent ), kenne die Youtube Api nicht und Kodi nur wenig,aber kenne Python schon recht gut. Ich habe mit h3ud3nt3uf3l (nun da ich den Namen das erste Mal tippe...) schon auf github Kontakt gehabt, Nutzername ist auch imsodin.
Bezueglich Sprache: Um sich untereinander abzusprechen ist Deutsch super solange es alle devs verstehen, aber alles was nach aussen kommt (docstrings, Wiki, Kommentare, ...) sollten unbedingt Englisch sein, damit die maximale Anzahl Nutzer und gelegentliche Code-Beitraeger erreicht werden kann.
Gruss Simon
