Plugins schreiben

  • So, zuerstmal auf deutsch :smiling_face:


    Es gibt ja schönerweise eine Menge an Addons für enigma2 bzw. die 7025.


    Wir würden gerne ein paar Dinge verbessern, um das Leben von uns, euch Plugin-Schreibern und vorallem den Anwendern ein wenig zu erleichtern.


    Beispielsweise würden wir gerne etwas bauen, dass man ein Plugin nur noch auf CF Karte / USB Stick kopieren muss, und in die Box schieben muss. Enigma müsste das dann als Plugin erkennen, und zur installation anbieten.


    Momentan gibts ein paar Gründe, warum das scheitert - vielleicht können wir die ja gemeinsam aus dem Weg schaffen.


    a.) Distributionsformat


    Viele Addons werden als .tar.gz verteilt, wo einige Dateien drin sind. Meist muss man dann manuell noch irgendwelche Dateien edieren. Das ist natürlich irgendwie ungünstig für den User.


    Die von uns bevorzugte Methode zum verteilen von nachinstallierbarer Software sind ipkgs. Die kann man dann sehr einfach ("ipkg install <dateiname>") installieren, und vor allem auch wieder deinstallieren ("ipkg remove <packetname>"). Weiterhin kann man packete updaten, und, sofern man das koordiniert, auch online bereitstellen und updaten.


    IPKGs zu bauen ist nicht weiter kompliziert. Man muss dafür kein Openembedded benutzen - ein ipkg ist nichts weiteres als archiv mit effektiv 2 dateien - einmal einem .tar.gz, welches einfach so entpackt wird, und einem weiteren .tar.gz mit 4 control files - hauptsächlich mit meta-informationen wie dem packetnamen, beschreibung, abhängigkeiten etc., sowie skripten, die optional vor/nach der installation/deinstallation ausgeführt werden.


    Ein IPKG zu erstellen ist also wirklich keine magische sache. Man muss einmal sein control file zusammenstellen, und das wars.


    Es wäre also ein erster schritt, wenn addons als IPKG angeboten werden würden. Wir würden auch sehr gerne diese online so zur verfügung stellen, dass man sie im Plugin-Menü per fernbedienung installieren kann.


    b.) Patchen von dateien


    Es ist sehr problematisch, wenn Addons irgendwelche dateien überschreiben. In den letzten Monaten waren ca. 90% der crashlogs, die wir zugesandt bekommen haben daraus begründet, dass ein Addon eine enigma2-Datei einfach überschrieben hat, so dass diese auf einer älteren Version basierte, die mit dem Rest nicht kompatibel war.


    Generell sollte es nicht nötig sein, Dateien komplett zu überschreiben. Wir bemühen uns generell, an allen sinnvollen stellen Plugin-Abfragen einzubauen, so dass ein Plugin sich sauber registrieren kann, und dann z.b. in der "Extensions"-Liste auftaucht. Wenn jemandem etwas fehlt (weil er z.b. ein schöneres Mainmenu machen will), sind wir gerne bereit, eine Funktionalität einzubauen, die es ermöglicht, an weiteren Stellen nach Plugins zu suchen.


    Selbst wenn diese funktionalität nicht gegeben ist, kann man einzelne funktionen ersetzen - python sei dank.


    ein einfaches beispiel dazu:

    Code
    >>> def a():
    ...     print "a"
    ...
    >>> def b():
    ...     print "b"
    ...
    >>> a = b
    >>> a()
    b


    auch wenn das nicht so schön ist wie eine saubere Einbindung ist es immernoch besser als andere Dateien zu überschreiben.


    c.) Weiterentwicklung


    Auch wenn wir es nach möglichkeit vermeiden, gibt es immer mal Änderungen, die auch Änderungen von Plugins erfordern. Sofern von den Entwicklern erwünscht wäre es z.b. eine Möglichkeit, die Plugins irgendwo in ein CVS zu tun, so dass dort auch andere Leute etwas zu beitragen können - natürlich alles optional. Auch wenn wir irgendwelche enigma2-Änderungen machen, könnten wir sehen, dass wir die Plugins dann aktualisieren.



    Was haltet ihr von diesen Vorschlägen?

  • Moin tmbinc,
    davon halte ich ne Menge. Wenn wir schon ein Packetverwaltungstool auf der Box haben, sollten wir das auch benutzten.


    zu a)
    Ich habe mir das mal als Anlass genommen, mir das HOWTO aus Reichi´s Wiki per IPKG-Buildscript mal nochmal angeschaut. Und was soll ich sagen: Diesmal hat es geklappt. Ich hoffe das Packet im Anhang ist so korrekt.


    zu b)
    Hm, mein SHOUTcaster, der Newsfeedreader und der Webcamviewer waren alles reine Plugins und haben nur eigene Dateien mitgebracht.
    Das einzige TAR.GZ (siehe a ) was Dateien überschrieben hat, war mein Webinterface Modding. Und das hat eigentlich das ganze Webinterface-Plugin überschrieben :smiling_face:
    Reine "E2-System-Dateien" will ich schon gar nicht überschreiben, da ich die Auf/Abwärtskompatibität nicht versauen will.


    zu c)
    Wenn ihr das Packet mit ins CVS aufnehmt, freue ich mir nen Knüpp in den Bauch :smiling_face:
    Wobei man die Konfigdatei mit in die /etc/enigma2/settings aufnehmen könnte... Hat mir aber auch einmal Arbeit abgenommen, als ihr dann das Konfigsystem verändert habt. :smiling_face:


    >>> greet = "".join(["s","c","h","ö","n","e"," ","G","r","ü","s","s","e"])
    >>> print greet
    schöne Grüsse
    3c5x9


    PS.: Dann wäre es evtl. nicht schlecht, wenn ihr auch .ipk als Extension als Anhang im forum erlaubt :smiling_face:

  • Ein paar Inputs von gutemine:


    im Multiboot 8.4 wird es das feauture geben ein multiboot.sh enable vtp zu machen.


    mit vt werden /var und /tmp statt im tempfs als Partitionen auf CF Karte gemountet.


    Mit p wird /usr/lib/enigma2/python/Plugins/Extensions ebenfalls
    als weitere partitione auf CF gemountet.


    Ich denke das ist so am saubersten und wenn man die CF Karte dann nur ueber das existierende Extensions directory druebermountet ist das original Extensions ja noch da (die originalfiles wie tuxtext werden natuerlich auch auf Cf Karte kopiert).


    Man kann dann natürlich keine Images von CF Karte booten, aber das ist ja eh nicht jedermanns Sache.


    Bezglich ipkg - Prinzipiell OK, und auch nicht so kompliziert, nur wenn ich 2 stufige Installationen habe (wie beim Multiboot - auspacken und enablen weil alles am Schluss auf CF karte sein soll, nur ist die beim auspacken halt noch nicht so wie sie sein soll)


    Iipks gibst ja durch die 7025 schon länger, haben sich aber (bei mir aus Faulheit muss ich zugeben) nicht wirklich durchgesetzt.


    Es wäre daher trotzdem nett wenn CVS Images trotzdem auch tar.bz2, tar, gz, rar files die entsprechend mit direkten Pfaden gepackt sind auspacken könnten - nicht umsonst habe ich das in der Zwischenzeit alles beim Multiboot bei den Install options dazugepackt und auch das unrar auf die 7025 portiert.


    Ich habe schon vor 6 monaten gefragt ob man dem enigma nicht eine autoinstall option verpassen könnte wo files die auf bestimmten Platz mit bestimmten Namen liegen entweder automatisch ausgeführt/Installiert würden, oder beim booten gefragt wird ob man damit was tun soll - schön wenn es endlich auch verstanden wird das das nicht so schlecht wäre - jeder PC wirft nachdem die Spiele CD reingeschoben wurde das autostart an !


    Bezüglich dem Patchen von enigma2 dateien - nun das das nicht so toll ist wissen wir alle, andererseits sind es oft wirklich nur ein paar Zeilen code die fehlen (Siehe mechatrons LCD Uhr Standby patch, oder den Sleeptimer, Wakeuptimer dmit fixen Zeiten zum Stromsparen den ich machen will)


    Solange man damit sinvolle Anregungen fürs CVS geben kann denke ich ist es schon OK es so zu tun, da liegt meines Erachtens die Verantwortung eher beim User zu wissen was er tut. Ich würde mir da eher eine einfache Möglichkeit wünschen im python CVS Stände, Imagenamen, etc abzufragen, weil dann die python erweiterungen ein self.checkdependency machen zu lassen und wenn es nicht passt brav nichts zu tun wäre schon mal eine Verbesserung. Ausserdem ist es ja nicht nur der python code - für den hiJack habe ich das Darstellen der Uhr und von bitmap logos (statisch und animiert) in C portiert, scheue mich aber davor zurück diese routinen jetzt einfach in die lcd.ppc reinzutun und mit SWIG zu binden, so das man Sie auch im python nach Bedarf aufrufen kann.


    Daher erstmals der hiJack dameon, was aber gerade für solche Sachen keine dauerhafte Lösung ist.


    Ob alle gerne mit CVS arbeiten ist wiederum eine Frage die schwer zu beantworten ist, weil obwohl es nicht schwer ist stellt es schon einen overhead dar den man sich aufbürdet, und damit sinkt wieder die Motivation von Neulinge was beizutragen, was wiederum der Plugin Entwicklung eigentlich nicht guttut.


    Ich denke an den interessanten stellen wäre macnhmal im Standard einigma2 ein paar exit points nicht schlecht wo man sachen geordnet dazutun kann - für das WebIF Modding habe ich das mal ausprobiert ob man nicht einfach mit os.path.exists nachschauen kann ob es ein addon gibt und das dann vom jweiligen python halt einfach mal aufruft (soowohl die import * from, als auch die Hauptroutine der Erweiterung mit vieleicht standardisierten parametern wie session,...).


    Stellen wo das nicht schlecht wäre sind z.B. die Timerprogrammierung, während dem start oder standby. Also z.B. wenn standby vom enigma2 ausgeführt wird und es existiert ein StandbyCustomActions.py dann wird das vom enigma ausgeführt, wenn nicht dann halt nicht. Und man kann da dann reinschreiben was man halt noch gerne bei Standby tun will. wenn Euch das os.path.exists nicht gefällt dann macht halt leere dummy files wo praktisch nur ein Kommetar drinnensteht "add your custom standby/startup/timer options here" und sofort return gemacht wird


    Vieleicht bin ich bei der ganzen Sache aber auch einfach nur als schlechtes Beispiel gut und alle anderen würden es eh gerne so schön ordentlich machen ...


    Ich finde es aber super das Ihr über solche Sachen ernsthaft nachdenkt
    und uns das Leben leichter machen wollt, also lasst uns weiter diskutieren und die Welt/Dreambox verbessern :smiling_face:


    LG
    gutemine

    8 Mal editiert, zuletzt von Lost in Translation ()

  • Zum installieren von Packeten auf andere Dateisysteme gibts übringes "ipkg install <pn> -dest <dest>" (dest z.b. "hdd"), und dann "ipkg-link". Finde ich eine sehr schöne und saubere Lösung, und ist natürlich auch Plugins machbar. (Evtl. müsste man das für .pyc files fixen).


    Was bringt denn .tar.gz? Nur, damit man nicht einmal ein Script schreiben muss was daraus ein IPKG baut? Sorry, aber das gilt nicht :winking_face: Ausserdem enthält ipkg solch sinnvolle Dinge wie dependencies etc. Das in python nachzubauen ist definitiv mehr arbeit, als ein IPKG zu erstellen. Mal ganz im ernst - wozu ein "unrar"? Warum sollte ein Plugin-Entwickler ein rar machen, wenn .tar.gz (oder darauf aufbauend IPKG) out-of-the-box geht? unrar dürften mal eben ein paar hundert kb unnötiges binary sein. Das flash ist doch schon fast voll.


    Gerade mit den paar Zeilen die fehlen - es geht nicht um die paar Zeilen, sondern um den Rest der datei! Wenn sich dort irgendwas ändert, auch wenn es garnicht die zu patchende Sache betrifft, wird alles schiefgehen. Und die >100 Crashlogs, die nur daraus resultierten, dass das MovieLookout-Plugin die MovieSelection.py mit einer älteren Version überschrieben hat, (und die dazugehörigen entsprechend frustrierten User) möchte ich lieber garnicht erwähnen...


    Die Verantwortung dafür dem User zu übertragen geht nicht. Woher soll der arme User wissen, welche Version von welchem Plugin mit welcher Enigma version zusammen funktioniert? Und vorallem bekommt er das Plugin nicht mehr deinstalliert, wenn es nicht funktioniert.


    Wie gesagt, du kannst heute eine Menge der Enigma funktionen (ich behaupte fast alles) verändern, ohne dass man was patchen muss (beispiel hatte ich ja gepostet). Bei berechtigtem Interesse bauen wir dann gerne "Hooks" ein.


    Das enigma GUI/GDI interface ist eigentlich "genug", um alles mögliche an Grafikoperation zu machen. Aber vielleicht übersehe ich ja eine Notwendigkeit - was genau fehlt dir dort, um deine Anzeige zu gestalten? Denk bitte auch daran, dass zukünftige Dreamboxen vielleicht einmal ein anderes Display bekommen werden - aber natürlich nur, wenn man das GDI von enigma benutzt.


    Natürlich kann dir niemand vorschreiben, wie du deine Addons gestaltest. Ich würde es nur schade finden, wenn enigma am anfang erstmal von einigen MB an Files MD5-Summen erstellen muss, um dann möglicherweise eine Warnung anzuzeigen, dass es nicht ordentlich funktionieren wird. Das ist nicht wirklich im Sinne einer "offenen Box". Allerdings schiebt der Anwender einen Crash erstmal auf uns, egal wieviele Addons er vorher installiert hat. Damit haben wir dann ein ganz gewaltiges Problem.

    • Offizieller Beitrag

    @gutemine:


    Du willst doch nicht allen Ernstes sagen, man soll .tar.gz's nehmen obwohl man einen vollwertigen Paketmanager hat?!
    Der einzige sich mir erschließende Grund warum man bei $Fremdimage keine ipkgs einsetzt ist in meinen Augen wohl, dass die Leute da nicht mehr einfach alles wild zusammenschustern können sondern sich auch mal etwas Gedanken über das was sie da in's System "implantieren" machen müssen.


    Man kann mit Hilfe von ipkgs so ziemlich alles lösen was man will, das geht los von irgendwelchen Abhängigkeiten bis hin zu post-/pre installation-/removal Scripts.


    Ich persönlich hallte es absolut nicht für sinnvoll und aus diesem Grund auch in keinster für Art und Weise erstrebenswert, einen Support für tar.gz oder sonstwasfürkomische Formate einzubauen wenn man ohnehin einen vollwertigen Paketmanager hat.


    Wie tmbinc schon erläutert hat kann man auch innerhalb eines Plugins eine Klasse komplett überschreiben (so man das will).
    Ja, Konflikte können trotzdem auftreten, werden aber dann durch eine einfache Deinstallation des entsprechenden Plugins wieder beseitigt.


    Wie die Meisten sicher wissen bin ich einer der Wenigen die Ihr "Zeug" i.d.R. als IPK anbieten.
    Wenn man sich dann auch noch an die Namenskonvetionen für enigma2 Plugins hält kann man die Erweiterungen ganz bequem über GUI wieder deinstallieren.
    Offensichtlich sind die Leute damit bisher gut zurecht gekommen, denn keiner hat sich bei mir beschwert, dass es kein tar.gz ist.
    Ein weiterer Vorteil ist, dass man ganz bequem "Inofficial Extensions Mirrors" aufsetzen kann die dann von den Leuten nur noch eingetragen werden müssen.
    Ja, man könnt das auch anders lösen, aber man hat doch alles schon da, warum das Rad neu erfinden?!


    Was ich von dem hijack Daemon halte willst du vmtl. eh nicht hören deshalb erspare ich mir jeglichen Kommentar zu dem Ding.

  • tmbinc


    Danke fürs Feedback - deswegen habe ich ja auch meinen Input gepostet - also kurz noch Feedback zum Feedback und dann kann ich eh nicht viel mehr von meiner Sichtweise beitragen.


    Ich verspreche also mir so wie 3c5x9 nochmal das ipk Wiki anzuschauen, OK :smiling_face: Wobei dependencies oft auch nur ein falsches Gefühl von Sicherheit darstellen - wozu gibt es die schönen -force beim ipk :smiling_face:


    unrarar liegt beim multiboot übrigens eh auf Cf Karte :smiling_face:


    Ihr dürft halt auch nicht vergessen das viele Ihr Zeug auf einem WindowsPC packen, und da hat Winrar, Winzip&Co halt sein Standing.


    Also wenn Ihr über die paar sinvollen Hooks nachdenken würdet wäre das schon sehr nett, wie gesagt wenigstens start und stop wäre schon hilfreich, und ins startup hook könnte man dann ja auch gleich den installationcheck als Beispiel einbauen - so in der art wenn IPK file gefunden auf /media/cf dann fragen was machen. Ähnliches gilt für das stoppen, nur eben um Erweiterungen vieleicht auch sauber zu beenden,...


    Und zum GDI - Wenn mir wer sagt wie ich in einem aktuellen CVS Image eine bitmap direkt vom python als logo auf den LCD zaubern kann bin ich sofort dabei. Tipps are welcome !


    Reichi


    Du hast ja im Prinzip recht, das man nicht jeden Blödsinn implementieren muss, aber aus meinem Geschäft weis ich halt das oft der kunde einfach recht hat (obs gescheit ist oder nicht).


    Ich weis das der hiJack eigentlich ziemlich pervers ist, ich wollt aber einfach sehen ob ich alles auch ohne enigma zusammenbringe (GUI, Input Handling, Device handling für Framebuffer, LCD,..). Ausserdem habe ich ihn geschrieben um Fernbediienungsmarkos zu implementieren und eine Sinnvolle Verwendung für die shift Taste zu haben- das LCD Zeugs hat sich nur vorgedrängt. Und es gibt ja noch ein paar andere Framebuffer sachen die ich gerne auf meiner 7025 hätte, und dafür wars eine nette Fingerübung und sonst nichts.


    Und bitte vergiss nicht das ich manchmal auch Sachen einfach mache weil ich Spass dran habe zu sehen ob es geht und dabei was zu lernen, nicht um die Welt damit besser zu machen. Ausserdem sind viele meiner sachen als Motivation zu sehen es besser zu machen, und ich bin oft verblüfft wie gut das funktioniert. Also nicht böse sein, ich habe mit meiner Rolle als Hofnarr kein Problem.


    LG
    gutemine


    PS: Trotzdem war es lustig den alten d-box lcd code aus tuxbox Zeiten schnell auf die 7025 zu portieren und zu sehen ob er noch geht (in summe eh nur 2h arbeit für die ganz grosse Digitaluhr, Bitmap, animierte logos und ein paar gimmicks wie den stars lcd screensaver oder das hiJack Logo). Eigentlich seit Ihr aber selber schuld - als ich im Code gesehen habe das ihr fürs LCD die alten dbox/tuxbox routinen im swig gebunden habt bin ich halt auf die Suche gegangen was as da sonst noch gibt :smiling_face:

    10 Mal editiert, zuletzt von Lost in Translation ()

  • Was ich eher Schade fand, war, dass das Bootsystem umgestrickt wurde. Früher konnte man schön mit update-rc.d einzelne Teile deaktivieren und dafür seine eigenen Init-Skripte reinfummeln. Eben ganz in der Paket-Philosophie.


    Mittlerweile gibt es wieder wie bei der dm7k nur ein Skript, was somit verhindert, dass man mit einem ipkg etwas im Bootprozess verändert, ohne eben diese Datei komplett neu zu ersetzen.


    In meinen Augen passt das nicht ganz zusammen :winking_face:


    Zur enigma GDI/GUI: Könnte man in e2 wieder den Patch reinnehmen, dass auch PNGs mit Platten < 8bit funktionieren?

  • LittleBoy: man kann ja weiterhin scripte dazupacken, und im Bootup sind eigentlich nur sachen drin, die sowieso gemacht werden müssen.


    Der grund war eigentlich, dass es die Bootzeit extrem verlangsamt hat, weil die Busybox doch sehr lahm ist.


    Was das PNG < 8bit angeht, ja, macht sicherlich sinn :smiling_face:


    gutemine:


    Klar lässt sich jeder dependency check aushebeln. Aber ein "rm -rf /" kann auch niemand verhindern. Ziel ist halt, alles per Fernbedienung machen zu können - und da ist das eingeben von "-force" dann natürlich schlecht :winking_face:


    Start/Stop hooks gibts schon ewig - siehe z.b. doc/PLUGINS, oder, als beispiel das Webinterface plugin, das SimpleRSS plugin oder das Fritzcall Plugin.


    evtl. benötigst du auch WHERE_SESSIONSTART, wenn du was darstellen willst.



    wegen dem LCD: du kannst doch einfach ein Pixmap erstellen, und per "setPixmapFromFile" dort ein PNG reinladen. oder die PNGs per hand laden, und dann mit "setPixmap" setzen. oder das PNG einfach im Skin laden, wenn es statisch ist.
    Beispiel für das Laden mit "setPixmapFromFile" ist die z.b. "Preview"-Funktion vom Skin-Chooser, der PicturePlayer z.b. lädt seine pixmaps per hand (wobei du loadPNG benutzen solltest), und setzt sie dann mit setPixmap, und für das laden aus dem Skin such einfach mal nach "pixmap=" in data/skin_default.xml.

  • tmbinc


    Es ist zwar nett wenn Ihr sagt die Hooks gibts längst, aber wenn es keiner weis (oder so wie ich vieleicht zu Faul zum Suchen war) - womit wir wieder beim Thema enigma2 & Doku wären.


    Ich weis schon das Ihr keine roten Pfeile im Sourcecode für DAUs machen könnt bitte hier den Müll reinstopfen, aber manchmal wäre halt ein How-To, mehr Beispiele, etc, nicht so schlecht.


    Das sind aber andere Geschichten und ich bin auch froher als manch anderer, dass Ihr diesen Thread berhaupt angefangen habt (weil da gehört auch Mut dazu zu fragen wie man etwas besser machen kann).


    Und zu den Tipps - auf jeden Fall DANKE !


    Mir war aber nicht klar das ich das auch mit dem LCD machen kann, ich probiers halt mal aus.


    Ausserdem wollte ich ja auch rausfinden wie es mit bootlogos am LCD aussieht BEVOR enigma startet :smiling_face:


    LG
    gutemine

    4 Mal editiert, zuletzt von Lost in Translation ()

    • Offizieller Beitrag

    Wenn man die Jungs nett fragt kriegt mal eigentlich immer eine Antwort wo etwas zu finden ist.


    I.d.R. reicht ja ein Ansatzpunkt von dem aus man sich dann problemlos selbst einlesen kann und genau den Ansatzpunkt haben Sie mir bisher immer geliefert, ganz egal ob das nun tmbinc oder Ghost oder auch jemand anders war.


    enigma2 ist relativ komplex (jedenfalls übersteigt wohl es die Komplexität von Projekten des durchschnittlichen reinen Hobbyprogrammierers), eine Doku wäre natürlich gut... nur wer die jetzt noch schreiben kann/will... ich glaube niemand ;).


    Im übrigen habe ich das Meiste bisher auch ohne Nachfragen gefunden, man guckt sich einfach an, was gibt es, was kann das und findet dann eigtl. fast alles was bereits implementiert ist an irgendeiner Stelle in der GUI, da die Dateien ja wirklich sinnvoll benannt und strukturiert wurden ist es dann i.d.R. kein Problem mehr die zugehörige Stelle im Code zu finden - ein bisschen guter Wille seitens des Programmierers vorausgesetzt.

  • diese Doku hatte ich glaube ich schon gelesen, und glaubt mir ich suche eh gerne und mit gutem Willen (aber vieleicht weniger Geduld als Andere) :smiling_face:


    Ist so wie Ostereiersuchen, man freut sich über jedes das man ins Körbchen tun kann.


    Noch eine kleine Bitte hätte ich aber doch noch:


    Ich würde mir eine einfache Methode/PythonAPI für Plugins wünschen Einstellungen, Werte, etc. von Plugins in ein Setting File (oder besser gleich in das Standard Enigma Settings file dazu) zu schreiben und zu lesen.


    Ich denke nämlich das wäre auch ein GROSSER Schritt um Abhängigkeiten, checks zwischen Plugins und Standard sauber zu implementieren.


    Und wie üblich bitte ich um Verzeihung wenn es das schon gibt und ich nur zu Dumm war es zu finden.


    PS: Und glaubt mir, der wer list meine Doku eigentlich Frust ist mir vom Multiboot NICHT unbekannt !


    LG
    gutemine

    3 Mal editiert, zuletzt von Lost in Translation ()

  • tut mir ja leid dass ich immer meine eigenen Demo-Plugins zitieren muss, aber im "Fritzcall"-Plugin ist das folgendermaßen drin:


    a.) erzeugung der config-einträge:


    einfach *global* folgendes tun:


    config.FritzCall = ConfigSubsection()
    config.FritzCall.hostname = ConfigIP(default = [192,168,178,254])
    config.FritzCall.enable = ConfigEnableDisable(default = False)


    (Es gibt ne Menge von verschiedenen Config-Einträgen, z.b. ConfigYesNo, ConfigInteger etc. - 'grep' ist dein freund.)


    b.) benutzen der einträge


    einfach mit "config.FritzCall.enable.value" - in diesem fall ist das ein boolean.


    c.) verändern der einträge, aka. "setup menu"


    am besten einfach erstmal dort abgucken.





    (*) ich geb zu, dass meine config-pfade nicht dem entsprechen, was in doc/PLUGINS steht. Das sollte man mal ändern...

  • OK, das FritzCall ist zu neu, das habe ich noch nicht mal angeschaut (habe keine solche Box um es zu benutzen).


    Aber danke, dann wart Ihr die letzten Monate eh recht fleissig und wir haben Euch noch mehr lieb !


    Ich probiers am Wochenende gleich mal mit dem Wakuptimer ( fürs Deepstandby) aus in die Konfig die Wakupstunde zu schreiben.


    Der Thread heisst ja auch Plugin schreiben, also sind ein paar aktuelle Tipps durchaus sinvoll.


    PS: Und meine doku hinkt auch immer hinterher ...


    LG
    gutemine

  • Hi !


    Nachdem gutemine jetzt brav ipk Pakete aus Ihren Plugins macht und das auf der Dreambox selber macht anbei das ipkg-build script das ich dafür verwende. Im Prinzip ist es zu 99% das originale so wie es vom author im header steht, ich hab nur einen kleinen FIX eingebaut.


    Das tar aus der Busybox nimmt zwar den --exclude parameter, um das CONTROL directory nicht ins daten paket dazuzupacken, ABER ignoriert es dann.


    Man kriegt dann damit beim auspacken jedesmal in / root ein /CONTROL directory, und sobald man mehrere ipks installiert mit diesem Problem schreit es auf weil die das dann jeweils überschreiben wollen.


    Ich hab das einfach im shellscript gefixed indem ich --exclude nicht mehr verwende sondern die files ohne CONTROL mit ls -1 | grep -v CONTROL erstellen lasse.


    Ich denke für Leute die kein OE haben und trotzdem ipks bauen wollen ist es ganz nützlich.


    Gleichzeitg ist es aber noch nicht 100% compatibel weil es am Schluss tar verwendet um alle pakete zusammenzupacken statt dem ar command.


    Das ist zwar kein grosses Problem weil ipkg mit beiden Formaten umgehen kann (sprich solche ipk files können auch installiert werden), aber lästig wenn man von hand reinschauen will.


    Nachdem die busybox beim ar aber kein -c unterstützt habe ich hier noch ein kleines Problem:


    Es hat zwar vor einiger Zeit jemand ein komplettes ar binary gepostet und ich habs auch runtergeladen, finde es aber jetzt nicht mehr auf meiner Harddisk :smiling_face:


    Kann jemand das voll funktionsfähige ar binary für die 7025 nochmal hier posten oder per PM schicken, ich passe dann das ipkg-build script entsprechend an, und mach ein ipkg-build*.ipk draus damit die Leute dann mit dem Wiki Eintrag zur Erläuterung zusammen alles haben was man benötigt um ipks auf der 7025 selber zu bauen.


    EDIT - ar wurde gefunden, kit zum ipkg builden mit ar auf der Dreambox ist im nächsten Reply von gutemine


    LG
    gutemine

    4 Mal editiert, zuletzt von Lost in Translation ()

  • OK, habe tip bekommen mal in den binutils nachzusehen - schön blöd von mir :frowning_face:


    Anbei also ein kleines ipkg-build.tar.bz2 das sowohl die voll funktionsfähige ar als auch das entsprechend angepasste ipkg-build enthält.


    Beide files werden auf /usr/local/bin abgelegt damit wenn das in Eurem Pfad inkludiert ist auch von überall ausgeführt werden kann.


    Für die syntax einfach ipk-build eingeben nachdem Ihr den kit auf /tmp FTPd und ausgepackt habt:


    cd /
    bunzip2 /tmp/ipkg-build.tar.bz2
    tar -xvf /tmp/ipkg-build.tar


    ipkg-build


    Damit sollte dann vom erstellen der directory struktur und des CONTROl directories abgesehen (das ist in Reichi's Wiki eh schön erklärt) ipkg machen selbst auf der Dream (fast) so einfach sein wie andere Archives erstellen.


    PS: wenn Ihr wollt kann ich auch daraus noch ein kleines ipk file machen :smiling_face:


    PPS: Und aufpassen das ar ist 2.7 MB gross, das verbraucht also ziemlich viel Speicher - evt nach dem auspacken woanders hin moven:


    mkdir /media/hdd/ar
    mv /usr/local/bin/ar /media/hdd/ar
    ln -sfn /media/hdd/ar/ar /usr/local/bin


    oder gleich den link der busybox loswerden und mit /usr/bin arbeiten:


    rm /usr/bin/ar
    ln -sfn /media/hdd/ar/ar /usr/bin


    LG
    gutemine