[ANNOUNCE] graphlcd 0.1.9

Nabend randy,

merci, für die neuen Version.

Alles Bestens!

Gruß
Wolfgang

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?

Zitat

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.

Zitat

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

Zitat

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.

Zitat

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

@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

Zitat

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

Zitat

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.

Zitat

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.

Zitat

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.

Zitat

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.

Zitat

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.

Zitat

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.

Zitat

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

Zitat

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.

Zitat

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

Dazu sage ich jetzt mal ganz bewusst garnichts.

Zitat

Originally posted by Mreimer

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.

Alles anzeigen

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...?

Zitat

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

Zitat

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.

Zitat

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

Zitat

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

Zitat

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.

Zitat

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.

Zitat

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.

Zitat

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