[ANNOUNCE] graphlcd 0.1.9

Zitat

Original von Mreimer
Der Linux-Desktop funktioniert. Ubuntu macht es vor.

Das stelle ich ja nicht in Frage. Aber zwischen "funktioniert" und "überzeugt" ist ein großer Unterschied.

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 (zusammen mit denen die das Plugin mitbringt) ist dann murks. Es sei denn es gibt ein System was Namensüberschneidungen verhindert.

Zitat

Originally posted by Mreimer
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.

Für das Argument brauchts aber wesentlich mehr als einen default Skin

Ich habe GraphLCD installiert, festgestellt das mit die Ausgabe nicht gefaällt und die dann im default.xml so konfiguriert wie ich sie will. Aus meine Usersicht ist das eindeutig ne Konfigurationsdatei.

Ich denke das gehört zu den Dingen die man einfach nicht eindeutig definieren kann.

Nächste Frage, "sources.conf": Resource oder Config?

cu

Der Name default.xml ist vielleicht etwas unschön gewählt. Das klingt dann so als ob da noch mehr davon liegen. Wäre nicht einfach skin.xml besser. Dann ist es 100% eine Konfigurationsdatei

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

Welche Motivation jetzt Microsoft hatte, das bei Windows anders zu machen als bei Unix/Linux weiß ich natürlich nicht. Ich halte zwar nicht viel von Microsoft, aber das kann ich mir ehrlich gesagt nicht vorstellen.

Gerald

Zitat

Original von Keine_Ahnung

Dann solltest du aber auch ein Konzept liefern wie "Frendskins" behandelt werden sollen.
Einfach mit nach /usr/vdr/graphlcd/skin packen (zusammen mit denen die das Plugin mitbringt) ist dann murks. Es sei denn es gibt ein System was Namensüberschneidungen verhindert.

Wieso ich? Aber egal, ist doch einfach, jedes Skin bekommt sein eigenes Verzeichnis unter usr/vdr/graphlcd/skin.

Gerald

Hallo,

um mal richtig blöd zu fragen: Warum können denn die Dateien des graphlcd-Plugins nicht in das jeweilige Plugin-Config-Verzeichnis? Beim Start des VDR kann man doch einen Config-Pfad angeben, unter dem sich auch die verschiedenen Plugin-Config-Verzeichnisse befinden. Wieso muss man dann jetzt entscheiden, warum manche Plugin-Dateien nach /etc, /usr usw. kommen. Über den Ort des Config-Pfad des VDR kann das doch dann jeder selbst festlegen wie es für ihn am schönsten ist...

Gruss Steve135

Zitat

Original von Steve135
Warum können denn die Dateien des graphlcd-Plugins nicht in das jeweilige Plugin-Config-Verzeichnis?

Wir reden doch schon die ganze Zeit darüber, dass Daten nicht ins Config-Verzeichnis gehören. Aber bevor es wieder ausartet ziehe ich mich lieber zurück.

Gerald

Zitat

Original von Copperhead

Das stelle ich ja nicht in Frage. Aber zwischen "funktioniert" und "überzeugt" ist ein großer Unterschied.

Ich habe schon über 5 Jahre nur noch Linux auf dem Desktop. Privat habe ich *garkeinen* Windows Rechner mehr. Wenn man nur Open Source Software nutzen will, dann ist ein Umstieg auf Linux zumindest problemlos möglich. Ich persönlich sehe keinerlei Anlass gerade beim Betriebssystem bei Closed Source zu bleiben. Ich persönlich bin vom Linux Desktop überzeugt. Ist meine persönliche Meinung und hier ohnehin Off Topic. Deshalb für dieses Thema von mir ein bedingungsloses EOD!

Zitat

Original von Steve135
um mal richtig blöd zu fragen: Warum können denn die Dateien des graphlcd-Plugins nicht in das jeweilige Plugin-Config-Verzeichnis?

Weil es keine Konfigurationsdateien sind.

Zitat

Original von Keine_Ahnung
Dann solltest du aber auch ein Konzept liefern wie "Frendskins" behandelt werden sollen.
Einfach mit nach /usr/vdr/graphlcd/skin packen (zusammen mit denen die das Plugin mitbringt) ist dann murks. Es sei denn es gibt ein System was Namensüberschneidungen verhindert.

Korrekt(er) wäre /usr/share/vdr/graphlcd/skin und ja: Da kommen dann auch neu hinzuinstallierte Skins rein. Wie du die installierst (Paketmanager oder durch manuelles Kopieren) hängt von den persönlichen Vorlieben oder der Distribution ab.

Zitat

Ich habe GraphLCD installiert, festgestellt das mit die Ausgabe nicht gefaällt und die dann im default.xml so konfiguriert wie ich sie will. Aus meine Usersicht ist das eindeutig ne Konfigurationsdatei.

Davon rät jeder Distributor erstmal ab, mit dem System mitgelieferte Dateien außerhalb von /etc irgendwie zu verändern. Grund: Ein Update des entsprechenden Pakets ersetzt deine geänderte Datei. Sowas passiert auch schonmal bei einem unvorsichtigen "make install". BTDTNT.

Richtig wäre gewesen: "default.xml" kopieren nach "meinskin.xml" und dann ändern.

Zitat

Nächste Frage, "sources.conf": Resource oder Config?

Config.

Und an der Stelle würde ich dann vorschlagen das Thema dringend auszulagern. Wir diskutieren hier schon seit geraumer Zeit am Topic vorbei.

Zitat

Original von Mreimer
Ist meine persönliche Meinung und hier ohnehin Off Topic. Deshalb für dieses Thema von mir ein bedingungsloses EOD!

Ach wenn dir dann die Argumente ausgehen, wird es plötzlich als Offtopic abgetan, obwohl es dich vorher auch nicht interessiert hat, ob On- oder Offtopic.

Das Thema ist Off-Topic. Außerdem ist Linux nicht Windows! Mit diesem sehr netten Link erkläre ich die Diskussion endgültig für beendet.

Das LFS-Thema ist ebenfalls Off-Topic. Wäre es sinnvoll wegen dem LFS-Thema einen Thread zu eröffnen? Eventuell vorher etwas im Wiki vorbereiten und dann zur Diskussion stellen? Oder gleich sein lassen und einfach selber weiter das System so gut wie möglich nach LFS-Standard einrichten?

Das einzige, dass es gibt, ist das hier:
http://vdr-wiki.de/wiki/index.php/Struktur
Mit LFS hat aber auch das nichts zu tun. Ist vermutlich noch Stand "LinVDR"?

Zitat

Originally posted by Mreimer
Davon rät jeder Distributor erstmal ab, mit dem System mitgelieferte Dateien außerhalb von /etc irgendwie zu verändern. Grund: Ein Update des entsprechenden Pakets ersetzt deine geänderte Datei. Sowas passiert auch schonmal bei einem unvorsichtigen "make install". BTDTNT.

Richtig wäre gewesen: "default.xml" kopieren nach "meinskin.xml" und dann ändern.

Genau, und dann installiert graphlcd mit dem nächsten Paketupdate einen neuen meinskin und mein eigener ist weg.
Wenn man es schon "richtig" machen will (so mit LFS und so) dann bitte richtig (also mal richtig nen Konzept überlegen, vorher) und nicht mal so eben schnell halb gar hingepfuschen. Weil mal LFS in den Raum zu werfen sagen erspart einem nicht das vorher Nachdenken.

Also wenns auf so etwas rausläuft dann Vote ich dafür das alles beim alten bleibt. Macht nämlich auch kein Spaß zu Diskutieren wenn von der anderen Seite außer Vorurteilen und Standartspüchen nix kommt (so an richtig praktischen Konzeptvorschlägen).

cu

PS: Ich liebe den VDR, ich nutze den VDR und ich werde ihnm in Zukunft weiter nutzen. Aber aus Usersicht ist das alles nen ziemliches Gemurkse. Weil Bestrebungen das ein wenig Userfreundlicher zu machen werden seltsamerweise nicht mit dem Argument das es zuviel Aufwand abgeschmettert, sondern von vornherrein weils dann... ja warum eigentlich, offensichtlich weils dann für die User zu einfach wäre. Schon irgendwie seltsam
Weil, warum einfach ne Datei irgendwo speichern, es geht ja auch mit Kommandozeile

Und nein, das ist keine Kritik an die Devs. Mit ist schon klar das die Zeit beschränkt ist und sowas dann in der Umsetzung dann doch seine Zeit braucht.
Es fällt mir halt nur immer wieder auf das das am Ende doch immer alles unnötig mühselig ist.

Ui ui ui, was hab ich da bloss wieder angerichtet?
Hab doch bloss ne Frage gestellt und gleich esacliert hier wieder alles ....

@ Randy

i18n sollte damit weg sein, ebenso alles was nicht mehr unter vdr-1.5.7 nötig ist

@ Mreimer

Zitat

War das unter Gentoo nicht bis vor kurzem "/usr/share/vdr/graphlcd/fonts",

Ja, ist auch noch immer so, bloss die .ttf fonts hab ich von dort gelinkt, weil wir dazu angehalten sind keine bundeld sourcen zu nutzen.

btw. einfach .ttf in die sourcen vom plugin packen und keine LICENSE information zu den fonts.
hmm, kann ärger geben
Gerade wenn das aus der Ecke hier kommt -->
Homepage: http://corefonts.sourceforge.net/
Description: Microsoft's TrueType core fonts
License: MSttfEULA

---

Also wo auch immer die logos, fonts, skins landen sollen,
weiss nicht die Argumente der Leute überwiegen die das lieber LHS conform haben wollen
oder ob sich die "Frickel System Fraktion" da durchsetzt.

wie auch immer,

mach die DIR's jeweils durch ein plugin parameter configurierbar !!!
( vielleicht solltest du erst garnicht einen default wert setzen) das nimmt dann allen den wind aus den Segeln)

eventuell kann man fuer die user mit eigenen skins/logos/fonts usw, noch irgend ne dir unter /usr/local/... definieren und vom plugin suchen lassen
Und diese DIR wird garaniert dort nicht von irgendwelchen paketmanagern angegriffen

Zitat

Original von Keine_Ahnung
Genau, und dann installiert graphlcd mit dem nächsten Paketupdate einen neuen meinskin und mein eigener ist weg.

"meinskin" steht für einen String, der deinen eigenen Skin treffend beschreibt. Wie groß ist denn die Chance, dass eine Datei mit einem von dir gewählten String überschrieben wird?

Einziger Fall, in dem das passieren kann, ist, dass du deinen Skin veröffentlichst, er in graphlcd übernommen wird, und durch ein Update deine Entwicklungsversion deines Skins überschrieben wird. Das ist für einen Entwickler aber "normal". Man kopiert dann halt aus dem Arbeitsbereich (/home/....) den Skin zurück ins System.

Ja, /usr/local existiert. Ob es aber sinnvoll ist, aus verschiedenen Verzeichnissen zu lesen, sei dahingestellt. Bei Slackware ist /usr/local generell leer. Auch vom Benutzer installierte Programme werden mit "prefix=/usr" gebaut. Bis vor kurzem wurden Libraries, die unter /usr/local/lib installiert wurden, bei Slackware nichtmal erkannt.

Zitat

Wenn man es schon "richtig" machen will (so mit LFS und so) dann bitte richtig (also mal richtig nen Konzept überlegen, vorher) und nicht mal so eben schnell halb gar hingepfuschen. Weil mal LFS in den Raum zu werfen sagen erspart einem nicht das vorher Nachdenken.

FHS existiert bereits. Er muss nur auf VDR übertragen werden.

moin,

nachdem ich festgestellt hatte , dass es doch noch nen grausameren Code als
im Music-Plugin gibt (liegt wohl daran , dass jeder da schon mal auf seine Weise dran rumgewerkelt hat ;)) , habe ich mir mal die Implementierung von
Span angenommen , weil es so eh nicht sinnvoll war.
Um das ganze flexibel zu gestalten habe ich es in etwa so wie beim Music-Plugin gemacht.
Quasi kann sich jeder selber was basteln ohne da was kompilieren zu muessen.

Naja und MCE kann sowas nicht Hint

Einfacher und komfortabler gehts nun nicht.
Platzierung , Groesse , Form etc. kann man selber anpassen.
(Fuer nen 240-fach Analyzer sollte aber schon ne Renderfarm vorhanden sein ;))
(Theme) Datei erstellen und "svdrpsend.pl PLUG graphlcd VIS $filename"
aufrufen oder nen Eintrag im Befehlsmenue vom Musicplugin ala

9-Band-mono                           : screen -A -m -d -S span /VDR/etc/plugins/music/language/german/scripts/music_glcdspan.sh 9-Band-mono.visual

music_glcdspan.sh sieht dann so aus ;

#!/bin/sh


/bin/svdrpsend.pl PLUG graphlcd VIS "$1"

9-Band-mono.visual in etwa so :

[code]
Description: 9-Band-mono
#
#
# ID               : 1=Mono | 2=Stereo horizontal | 3=Stereo vertikal
# CHANNEL          : Anzahl von Kanaelen (1= mono , 2=stereo)
# BARS             : Anzahl der Balken
# CHANNEL1LEFT     : X-Koordinate von ersten Balken ( bei horizontaler Anzeige Y-Koordinate)
# CHANNEL2LEFT     : s.o nur 2. Balken
# BARWIDTH.        : Breite von Balken in Pixeln
# DISPLAYWIDTH.    : Breite von Display oder Zeichenflaeche
# DISPLAYHEIGHT.   : s.o nur Hoehe
# BGCOLORISBLACK.  : invertieren 1=Ja 0=Nein
# OFFSETX1.        : Offset von Balken
# OFFSETY1.        : s.o
# OFFSETX2.        : s.o
# OFFSETY2.        : s.o
# FALLOFF.         : Falloff von Peakanzeige
# PEAKHEIGHT.      : Hoehe von Peak
# UPDATESA.        : Aktualisierungsrate in (ms)
# DISPLAYX.        : X-Koordinaten von Display bzw. Zeichenflaeche
# DISPLAYY.        : s.o nur Y-Koordinate
# MIXED.           : 0=Nur Analyzer sichtbar | 1= Auch andere Infos anzeigen
#
#
#
<value> .ID.              =1
<value> .CHANNEL.         =1
<value> .BARS.            =9
#<value>	.CHANNEL1LEFT.  =2
#<value>	.CHANNEL2LEFT.  =72
<value> .BARWIDTH         =12
<value> .DISPLAYWIDTH.    =146
<value> .DISPLAYHEIGHT.   =30
<value> .BGCOLORISBLACK.  =1
<value> .OFFSETX1.        =4
<value> .OFFSETY1.        =1
<value> .OFFSETX2.        =0
<value> .OFFSETY2.        =0
<value> .FALLOFF.         =20
<value> .PEAKHEIGHT.      =1
<value> .UPDATESA.        =1
<value> .DISPLAYX.        =0
<value> .DISPLAYY.        =0
<value> .MIXED.           =0

Das sieht dann real so aus.
VIDEO

Wenn Interesse besteht , kann ich mal nen Patch fertigmachen (mach ich sowieso ;))
Muss aber noch ne Waveform und nen Parameter fuers Mixen
der Anzeige einbauen.

Patch

Passende Themes fuer nen 140x32 sind dabei ( ./graphlcd/visual ).

Das ist nicht schlecht gemacht. Sieht gut aus.

Allerdings wäre es meiner Meinung nach sinnvoll erstmal zu warten, bis graphlcd den Skin-Support hat. Ich kenne das Skin-System von graphlcd, wie es bisher implementiert ist, nicht, aber IMHO sollten die Skins für die Visualisierung eine ähnliche Syntax bekommen.

Warum brauchst du ein Script das via SVDRP irgenwas auslöst? Ich hoffe doch auch mit deinem Patch läuft die Visualisierung sofort los, sobald Daten anliegen?

moin,
das funzt auch ohne script.
Das Plugin liest beim Start von VDR die Datei current.vis ein.

Mit dem/der Script/Anweisung stosse ich das Plugin nur an die
Daten aus der uebergebenen Datei zu laden, wie im Video zu sehen ist.

Es war eben bequemer als nen Setupeintrag oder nen Menue einzubauen und sich jedesmal dahin zu hangeln um das Ergebnis zu testen

Wenn da was dauerhaft gespeichert werden soll , dann muss das Themefile
nur nach current.vis kopiert werden.

Habe schon sowas vermutet. Ich habe nämlich gerade mal über den Patch geschaut.

Bleibt halt die Frage in wiefern das mit dem geplanten Theme-Support für graphlcd harmoniert.

Außerdem stört mich persönlich noch etwas, dass die Visualisierung das ganze LCD in Anspruch nimmt. Die alte Lösung hat noch Platz für Titel und Zeitleiste gelassen. Das ist aber vermutlich etwas, dass dann eben über den Theme-Support anpassbar sein sollte.

moin 2,

na dann schau halt mal genauer hin

Ausserdem steht doch oben im Beispiel von ner Themedatei :
# MIXED. : 0=Nur Analyzer sichtbar | 1= Auch andere Infos anzeigen

Bei der alten Loesung war ueberhaupt kein Platz , weil die Anzeige in ner
festen Groesse einfach ueber den Rest der Infos gepappt wurde.
...und zwar genau ueber meine Titelzeile
Allerdings hatte Chris auch garkein Display um das mal zu testen , soweit
ich mich erinnern kann.
Genau deshalb ist das hier ja entstanden.
Nun kannst du dir selber wo, wie , was einstellen und wenn du
"MIXED. =1" einstellst , dann werden auch die anderen Infos gezeichnet.
Im Video ist das zu sehen , da sind nur oben 2 horizontale Balken und ich hatte ja geschrieben
"Muss aber noch ne Waveform und nen Parameter fuers Mixen
der Anzeige einbauen. " . Mit "Mixen" war jetzt kein Musicmixer gemeint ,
sondern mixen mit anderen Infos.

Suche in display.c nach den Code , wenn du mir net glaubst

DisplaySA();
                                if(!showSA || GraphLCDSetup.Mixed) {
                                  DisplayReplay(replay);
                                  DisplayTime();
                                  DisplayLogo();
                                //DisplaySymbols();
                                  DisplayVolume();
                                  DisplayMessage();
                                }

showSA bekommt erst true , wenn da Daten vom Span Server kommen
(also ist das ganze auch Plugin unabhaengig , nur vorbeugend.. )
Na und GraphLCDSetup.Mixed hat halt den Wert vom Parameter "MIXED"
aus der Themedatei.