[ANNOUNCE] graphlcd 0.1.9

  • hallo,


    die naechste zusammengepackte version mit den letzen aenderungen und aktuellen logos/channel.alias;


    download:
    http://projects.vdr-developer.org/projects/graphlcd/files


    die aenderungen:


    graphlcd-base:
    - fixed compile error. http://www.vdrportal.de/board/…?postid=959952#post959952
    - changed graphlcd.conf back to original: http://projects.vdr-developer.org/issues/524
    - removed unneeded LDFLAGS: http://projects.vdr-developer.org/issues/530


    vdr-plugin-graphlcd:
    - fixed vdr 1.6.0 combatibility and several typos
    - added SVDRP support (TomJoad): http://projects.vdr-developer.org/issues/488
    - added SPAN support (Mreimer): http://projects.vdr-developer.org/issues/523
    - new: logonames.alias is now named channels.alias, which is maintained by wbreu


    und wie immer bitte fleissig den bugtracker benutzen, wenn probleme auftauchen:


    http://projects.vdr-developer.org/projects/graphlcd/issues



    gruss,
    -- randy

  • Moin,


    compilieren tuts erstmal :)


    Was ich gerne in der nächsten Version geändert hätte, den grep im Makefile von i18n.c auf i18.h ändern.
    Es ist nicht gewährleistet das die sourcen vom vdr in jedem system vorhanden sind.
    Bei den headern siehts da schon besser aus. Die information nach der du grep'st ist in dem headerfile auch vorhanden.
    Oder du schmeisst den support für <=vdr-1.5.13 ( war das glaub ich ) gleich ganz raus :)
    Dazu könnt ich dir nen completten Patch fertig machen...


    Weiterhin ist das fonthändling irgenwie beschissen gelöst.
    Ich halte das nicht fuer eine gute idee die fonts ( corefonts, *.fnt ) im source vom plugin zu bundeln
    Besser wäre es die systemeigenen installierten fonts zu nutzen.
    Das die in der etc plugin dir dann zum liegen kommen ist auch mist, --> LHS


    Unter gentoo, z.B., liegen fonts in /usr/share/fonts/(corefonts)/ darauf hin sollte das im source angepasste werden.
    btw. weis ich nicht in welchem path die bei anderen distris liegen.
    Können sich ja mal n paar andere distri user dazu äussern.


    Randy, soll ich dir mal zu den beiden Sachen nen bug/feature-request anlegen?

  • Quote

    Original von hd.brummy
    Unter gentoo, z.B., liegen fonts in /usr/share/fonts/(corefonts)/ darauf hin sollte das im source angepasste werden.


    War das unter Gentoo nicht bis vor kurzem "/usr/share/vdr/graphlcd/fonts", was IMHO auch ein besserer Default wäre. Die Fonts gehören erstmal zu graphlcd.


    Ich habe das bei mir so gelöst, dass es bei mir unter /etc/vdr/plugins/graphlcd entsprechende Symlinks nach /usr/share gibt.


    Nachtrag:
    http://mirror.hamakor.org.il/p…vdr-graphlcd-0.1.8.ebuild


    Hier sieht man eindeutig, dass Gentoo es genau so macht, wie ich schon seit längerer Zeit. Fonts liegen unter /usr/share/fonts/graphlcd/fonts. Das einzige, dass dieses ebuild macht, ist eine Handvoll Symlinks von /usr/share/fonts/corefonts in das Font-Verzeichnis von graphlcd. An der Stelle könnte man höchstens fordern, dass diese TTF-Fonts doch bitte via Fontconfig direkt aus dem System-Font-Verzeichnis geholt werden, sofern das nicht sowieso schon der Fall ist.


    Komisch, dass Gentoo einen Symlink von /etc/graphlcd.conf nach /etc/vdr/plugins/graphlcd/graphlcd.conf baut. Bei mir tut das schon seit einer Ewigkeit ohne diesen.

  • guten morgen,


    mhm, ich dachte ich haette das ganze i18n schon draussen ;) muss ich nochmal schauen.


    mit den fonts wird sich dann ab der "skin release" (vorraussichtlich 0.2.0) eh alles
    aendern, d.h. bitte nicht allzuviel wert darauf legen ;) aber patches sind wie immer
    gerne gesehen. primaer wuerde ich sie aber _jetzt_ auch nach /usr//share/vdr/... legen.
    da *.fnt wirklich nur von graphlcd kommen.


    aber warum nun graphlcd.conf nach /etc/vdr/plugins soll, verstehe ich nicht so recht: graphlcd-base
    hat auch noch ander eprogramme die es benutzen, nicht nur vdr. bei lcdproc liegt die
    konfig ja auch nicht unter /etc/vdr/plugins, oder?


    aber das waere mal eine idee, an mehreren stellen "danch zu suchen" - also z.b.
    im vdr config verzeichnis, unter /etc/ und /etc/vdr/plugins... dann waers auch wieder
    egal? dann muesste nur jeweils der install path geaendert werden.


    gruss,
    -- randy

  • Quote


    primaer wuerde ich sie aber _jetzt_ auch nach /usr//share/vdr/... legen.


    Am besten an die Stelle, an der es jetzt bereits unter Gentoo liegt:
    /usr/share/vdr/graphlcd/fonts
    Logos dann nach
    /usr/share/vdr/graphlcd/logos


    Quote


    aber warum nun graphlcd.conf nach /etc/vdr/plugins soll, verstehe ich nicht so recht: graphlcd-base
    hat auch noch ander eprogramme die es benutzen, nicht nur vdr. bei lcdproc liegt die
    konfig ja auch nicht unter /etc/vdr/plugins, oder?


    Vergiss meinen Kommentar zur graphlcd.conf. Ich habe nur gefragt, warum Gentoo den Symlink überhaupt anlegt. graphlcd.conf gehört nach /etc. Schon weil graphlcd-base eben auch vom VDR unabhängige Tools mitbringt und diese die Config auf finden wollen.

  • Quote

    Originally posted by Mreimer


    Am besten an die Stelle, an der es jetzt bereits unter Gentoo liegt:
    /usr/share/vdr/graphlcd/fonts
    Logos dann nach
    /usr/share/vdr/graphlcd/logos


    Warum den Kram im gesamten System verstreuen?


    Alle VDR Plugins legen ihre Config und ihre Ressourcen in <VDRConfDir>/plugins/<pluginname> ab. Und dieses Verzeichnes kann ein Plugin auch einfach ermitteln (wird vom VDR geliefert).



    BTW: Würden sich die Plugins mal einigen ihre Logos zu normieren wäre ein Speicherort außerhalb natürlich korrekt.


    cu

  • Stimmt. Das sich VDR und Co. recht wenig um FHS schert ist ein weitläufiges Problem. Ohne passende Make.config würde es auch kein /etc/vdr oder /usr/lib/vdr geben.


    Fakt ist, dass Ressourcen nichts unter /etc verloren haben. Dahin gehören normalerweise nur Konfigurationsdateien. Statisches, was mit dem Plugin ausgeliefert wird, gehört unter /usr/share.


    Das hat auch nichts mit "im gesamten System verstreuen" zu tun, sondern das ist eine unter Unix normalerweise übliche Norm, die nur von wenigen Programmen ignoriert wird (VDR... ;) ). Als Unix-Fortgeschrittener/Profi kann man so ohne viel Lesen und Suchen die gewünschten Daten finden, nur indem man dem logischen/üblichen Pfad folgt.


    Ist allerdings letztlich Entscheidung des Plugin-Entwicklers, ob er sich nach dem FHS richten will. Ich kann auch weiterhin meine Symlinks anlegen, dass meine Daten da liegen, wo sie hingehören.

  • @Mreimer


    Full ACK, aber dünnes Eis. Wegen gleich lautender Äußerungen wurde ich hier schon heftig attackiert.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • @Mreimer: Erstmal hast du natürlich recht, allerdings ist es IMHO wichtiger das es Einheitlich ist. Und so wie ich das verstehe ist das beim VDR halt nun mal so ;)


    Ein großes Aufräumen (inkl. einer Vereinheitlichung der EPG Images und Channellogos) wäre natürlich toll. Aber da die meisten Plugins nicht mehr gepflegt werden halte ich so was für aussichtslos.


    Wobei man sich jetzt auch noch wunderbar drüber streiten könnte was Ressource und was Config ist ;)
    Was ist denn mein eigenes Skin was ich speziell für mein Display erstellt habe (inkl. der speziell dafür gemachten Grafiken und Fonts)? Ist es Config oder Ressource?



    BTW: Und gerade bei den Skins fände ich es toll (entgegen dem was eigentlich richtig wäre) wenn man die Fonts auch im Skin Verzeichnis speichern könnte. Dann könnte man einen Skin einfach als ZIP Releasen und die User hätten wesentlich weniger Fummelei bei der Installation.
    Was die Usebility dann noch weiter steigern könnte wäre es wenn man das ZIP gar nicht erst auspacken müsste (ist unter Win z.B. üblich) ;)


    cu

  • Quote

    Original von Keine_Ahnung
    Was ist denn mein eigenes Skin was ich speziell für mein Display erstellt habe (inkl. der speziell dafür gemachten Grafiken und Fonts)? Ist es Config oder Ressource?


    Ressource


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Quote

    Original von Keine_Ahnung
    Ein großes Aufräumen (inkl. einer Vereinheitlichung der EPG Images und Channellogos) wäre natürlich toll. Aber da die meisten Plugins nicht mehr gepflegt werden halte ich so was für aussichtslos.


    Die relevanten Plugins werden entweder noch gepflegt oder laufen mit wenig Aufwand noch. Wenn letzteres mal nicht mehr der Fall ist, findet sich mehr oder weniger von alleine ein neuer Maintainer für das Plugin.


    Man muss auch nicht vereinheitlichen, sondern es würde ausreichen, wenn man sich beim Ablegen einfach an die FHS hält.


    /usr/share/vdr


    ergibt sich meiner Meinung nach von alleine. Nun könnte man darüber streiten, ob da noch ein "plugins" drunter soll oder ob man "graphlcd" direkt dort ablegt. Da Gentoo aber diese Entscheidung bereits abgenommen hat, könnte ich gut mit /usr/share/vdr/graphlcd leben.


    Zumindest ich habe dort dann noch /usr/share/vdr/bin mit Binaries, die nur für den VDR relevant sind. Also niemals von der Shell ausgeführt werden. Habe ich aber, soweit ich mich erinnern kann, auch von Gentoo übernommen.


    Quote


    Wobei man sich jetzt auch noch wunderbar drüber streiten könnte was Ressource und was Config ist ;)
    Was ist denn mein eigenes Skin was ich speziell für mein Display erstellt habe (inkl. der speziell dafür gemachten Grafiken und Fonts)? Ist es Config oder Ressource?


    Ressource. Hat gda aber schon geschrieben.


    Quote


    BTW: Und gerade bei den Skins fände ich es toll (entgegen dem was eigentlich richtig wäre) wenn man die Fonts auch im Skin Verzeichnis speichern könnte. Dann könnte man einen Skin einfach als ZIP Releasen und die User hätten wesentlich weniger Fummelei bei der Installation.
    Was die Usebility dann noch weiter steigern könnte wäre es wenn man das ZIP gar nicht erst auspacken müsste (ist unter Win z.B. üblich) ;)


    Unter Unix läuft eben vieles anders. Man kann, ohne viel zu fragen und zu fummeln, einfach ohne Nachzudenken die Dateien dort einsortieren, wo sie hingehören (sofern man einen Standard für die Ablage definiert). Das kann ggf. auch ein kleines Makefile machen.


    Bei Slackware sind alle Pakete eigentlich große Archive. Alle Dateien sind so abgelegt, wie sie letztlich im System landen müssen. Man könnte ein Slackware-Paket also einfach direkt auf / auspacken und die Installation wäre erledigt. Macht man aber nicht, da "installpkg" sich merkt was wo installiert wurde, um später ein "upgradepkg" oder "removepkg" zu erlauben.


    Nachtrag: Eventuell sollte man mal über ein FHS für den VDR diskutieren. /etc/vdr und /usr/share/vdr, bzw. /usr/lib/vdr und /var/cache/vdr sind selbsterklärend, aber ob man unter /usr/share/vdr noch ein "plugins" will könnte man durchaus mal diskutieren. Das Ergebnis sollte dann im deutschen und englischen VDR-Wiki niedergeschrieben werden.

  • Quote

    Originally posted by Mreimer
    Man muss auch nicht vereinheitlichen, sondern es würde ausreichen, wenn man sich beim Ablegen einfach an die FHS hält.


    Mit "Vereinheitlichen" meinte ich das man sich einmal auf ein System einigt und dann alle Plugins anpasst.


    Quote

    Originally posted by Mreimer
    Ressource. Hat gda aber schon geschrieben.


    Irgendwie wiederstrebt mir der Gedanke meine Displaykonfiguration (auch Skin genannt) an der ich eine Woche gearbeitet habe einfach so nach /usr/share/vdr/ zu packen (während in /etc massenweise Kram liegt den ich nie anfassen muss).
    Da erwarte ich dann doch eher Sachen die vom Orginalpaket kommen und im Zweifel beim Update einfach ungefragt überschrieben werden können.


    Quote

    Originally posted by Mreimer
    Unter Unix läuft eben vieles anders.


    Aber man darf durchaus Sachen machen die sich unter Windows bewährt haben ;)


    Und wenn da einerseits yaVDR und easyVDR kommen und den User so krampfhaft von der Kommandozeile fernhalten das sogar so grundlegende einmalige Systemeinstellungen wies Netzwerk und Samba Konfigurationpunkte im VDR Hauptmenue haben... ;)


    Wobei ich das jetzt nicht Argumentativ durchdrücken will, war nur mal sone Idee und Anregung aus Usersicht.


    BTW: Wenn man sich mal näher mit der Skin Sache beschäftigt dann wird man festellen das grobauflösende LCDs grundsätzlich anderst behandelt werden müssen als hochauslösende Röhrenmonitore/TFTs. Und das bedeutet, genau den richtigen Font für den Skin zu haben ist extrem wichrig. Einfach ein ähnlicher der genauso heisst passt hier einfach nicht. Deswegen die Idee die Fonts ins Skin Verzeichnis zu packen.


    Quote

    Originally posted by Mreimer
    Nachtrag: Eventuell sollte man mal über ein FHS für den VDR diskutieren. /etc/vdr und /usr/share/vdr, bzw. /usr/lib/vdr und /var/cache/vdr sind selbsterklärend, aber ob man unter /usr/share/vdr noch ein "plugins" will könnte man durchaus mal diskutieren. Das Ergebnis sollte dann im deutschen und englischen VDR-Wiki niedergeschrieben werden.



    Da ich schon länger ne Neuinstallation hinausschiebe (Debian mit VDR/Plugins von Source ohne Pakete) wäre ich sehr dafür. Ich würde das denn nämlich bei dieser Gelegenheit gerne nal richtig machen (und bin was FHS angehet auch noch am lernen und Konzepte erkunden, Bin eigentlich in Win Zuhause, da gibts ja nen komplett anderes Konzept).


    cu

  • Quote

    Original von Keine_Ahnung
    Irgendwie wiederstrebt mir der Gedanke meine Displaykonfiguration (auch Skin genannt) an der ich eine Woche gearbeitet habe einfach so nach /usr/share/vdr/ zu packen (während in /etc massenweise Kram liegt den ich nie anfassen muss).


    Irgendwie wiederstrebt mir der Gedanke ein Programm, an dem ich wochenlang programmiert habe, einfach so unter /usr/bin zu installieren.


    Merkst du was?


    Der normale User fasst eher /etc an, da dort konfiguriert wird. Bei den allermeisten Usern arbeitet unterhalb von /usr lediglich der Paketmanager.


    Es sei denn man ist Entwickler.


    Als Entwickler arbeitet man in einem Arbeitsbereich und installiert dann als Root in einen entsprechenden Systembereich. Der Arbeitsbereich sollte via Backup abgesichert sein.


    Quote


    Aber man darf durchaus Sachen machen die sich unter Windows bewährt haben ;)


    Dazu sage ich jetzt mal ganz bewusst garnichts.


  • Und warum soll dann die Displaykonfiguration nach /usr/share/vdr? Diese Idee verstehe ich halt nicht.
    Nur weil es ne XML und keine Plain/Text Konfigdatei ist in der man angibt wie die Displayausgabe aussehen soll? Oder weil hier auch Bitmaps zur Konfiguration gehören?


    Wenn ich nen Open Office Textdokument erstelle dann speichere ich dafür erstellen Grafiken doch auch nicht spereat unter /etc.


    OK, mitgelieferte Skin gehören nach /etc, aber die selbst erstellten...?


    Quote

    Originally posted by Mreimer
    Dazu sage ich jetzt mal ganz bewusst garnichts.


    Ach, ich hab schon manchmal das Gefühl das es nur darum geht es einfach irgendwie anderst zu machen als der Feind ;)


    Ich finde es ist jedenfalls sehr viel einfacher sich seinen Skin im Browser (z.B. auf der wiki Page die dann die Skins sammelt) anzuklicken und unter //vdr-per-Samba/usr/vdr/graphlcd/skins zu speichern als da erstmal mitels Puty auf die Kommandozeile zu gehen.


    Das keiner Lust hat das zu Coden lass sich als Argument natürlich gelten, aber das ohne Angabe von Gründen ("wir machen das nicht wie unter Win" ist kein Argument) abzulehen sehe ich nicht ein (jedenfalls kann ich mir dann keine Antwort darauf verkneifen ;) ).


    cu

  • Quote

    Original von Keine_Ahnung
    Ach, ich hab schon manchmal das Gefühl das es nur darum geht es einfach irgendwie anderst zu machen als der Feind ;)


    Das dauert aber noch lange, bis Linux überhaupt das Recht hat Windows als Feind anzusehen. Was Desktopfunktionalität angeht steht Linux immernoch sehr dumm da.


    Linux als Server oder Embedded-System (wie zb VDR) hat sich bewährt. Obwohl ich mir auch schon hab sagen lassen, das ein Windows-Server sehr genial zu administrieren ist.

  • Quote

    Originally posted by Copperhead


    Das dauert aber noch lange, bis Linux überhaupt das Recht hat Windows als Feind anzusehen. Was Desktopfunktionalität angeht steht Linux immernoch sehr dumm da.


    Wen wunderds, andere Betriebsysteme haben da nicht solche Hemmungen gute Ideen zu klauen ;)
    Und mit "ist OS, machs besser und jammer nicht" erreicht man die Breite Masse auch nicht.


    Und MS weicht gerade das mühselig eingeführte Userkonzept (Useraccount mit eingeschränkten rechten, Dateisystemrechte) wieder auf (Virtual Store, ne grausame Erfindung) um die User nicht mit Fehlermeldungen zu stören ;)


    cu

  • Quote

    Original von Keine_Ahnung
    Und warum soll dann die Displaykonfiguration nach /usr/share/vdr? Diese Idee verstehe ich halt nicht.
    Nur weil es ne XML und keine Plain/Text Konfigdatei ist in der man angibt wie die Displayausgabe aussehen soll? Oder weil hier auch Bitmaps zur Konfiguration gehören?


    Das sind keine Konfigurationsdateien, das sind die Daten die deinen Skin ausmachen. Wenn du deinen Skin für User konfigurierbar machst, z.B. um Senderlogos einzublenden, oder auch nicht. Das ist dann eine Konfiguration die nach /etc gehört.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Quote

    Original von Keine_Ahnung
    Und warum soll dann die Displaykonfiguration nach /usr/share/vdr? Diese Idee verstehe ich halt nicht.
    Nur weil es ne XML und keine Plain/Text Konfigdatei ist in der man angibt wie die Displayausgabe aussehen soll? Oder weil hier auch Bitmaps zur Konfiguration gehören?


    Man sieht das System immer aus der Sicht des Users. Der User "konfiguriert" nicht im Quellcode des Themes. Er installiert das Theme lediglich und das macht er unterhalb von /usr.


    Wenn dein Theme dagegen für den Benutzer Konfigurations-Optionen bereithält, dann dürftest du die von /etc her includen.


    Quote


    Ach, ich hab schon manchmal das Gefühl das es nur darum geht es einfach irgendwie anderst zu machen als der Feind ;)


    Nein. Es gibt nur ganz genaue Regeln wo was hin gehört.


    Quote

    Original von Copperhead
    Was Desktopfunktionalität angeht steht Linux immernoch sehr dumm da.


    Der Linux-Desktop funktioniert. Ubuntu macht es vor. Allerdings nur solange man nicht ins Geschäft will, um Software zu kaufen.

  • Quote

    Originally posted by gda
    Das sind keine Konfigurationsdateien, das sind die Daten die deinen Skin ausmachen. Wenn du deinen Skin für User konfigurierbar machst, z.B. um Senderlogos einzublenden, oder auch nicht. Das ist dann eine Konfiguration die nach /etc gehört.


    Dann solltest du aber auch ein Konzept liefern wie "Frendskins" behandelt werden sollen.
    Einfach mit nach /usr/vdr/graphlcd/skin packen ist dann murks.


    cu