nOpacity 0.0.3

Zitat von mini73

[...]

Code

git clone ... (kenne die genaue URL nicht)
....

http://projects.vdr-developer.org/git/skin-nopacity.git/

Bzw:

git clone git://projects.vdr-developer.org/skin-nopacity.git

Moin!

Ich hab mir den Skin jetzt auch mal angesehen: sieht schon geschmeidig aus!
Allerdings habe ich ein Problem mit den Schriftgrößen. Ich betreibe meinen Test-VDR an einem Monitor mit 1280x1024. Wenn ich in die Plugineinstellungen gehe, sehe ich viele "Schriftgröße ändern" Einträge, allerdings ist die default-Schrift so groß, dass ich nicht sehe, welche Schrift ich denn da wohl einstellen kann. Ich hab einfach mal alle auf 2 gesetzt, aber das hat auch nicht geholfen.
Hat jemand einen Tipp für mich?

Lars.

Wenn es so aussieht ([ANNOUNCE] skin nOpacity), sollte es helfen die Standard-Schriftgröße des VDR hochzudrehen: [ANNOUNCE] skin nOpacity

@yavdr-team
bei Gelegenheit das unstable ppa auf die 0.3 aktualisieren?

Torsten73 hab ich. aber irgendwie mag das nicht mit dem angepassten bild trotz yaepghd patch in vdr.
readme sagt nichts dazu. oder ist der patch noch nicht in 0.0.3 ?

die setup einstellungen bieten mir das einpassen an. das problem, es steht schon auf "ja".

displaymenuview.c:#ifdef USE_YAEPG

habs gefunden. ich suchte immer nach yaepghd. ich geh halt immer von einzelpatches aus, und nicht von der vorraussetzung des extensionspatches.
in einem einzelpatch hab ich das selten gefunden mit "ifdef"

solange bleibt halt das ganze deaktiviert.

ich hab grade keinen bock auf den ganzen kram.
es bezieht sich auf "soll das plugin/skin dann halt ein anderer patchen für yavdr"

um 180 pakete zu pflegen und jeder macht hier seinen eigenen scheiss bei den patches ist so dermassen anstrengend.
ich kann nur hoffen das meister kls den patch bald aufnimmt. aber ich schätze ihm ist das scheissegal.

tschuldigung das war nicht auf louis bezogen.
er ist ja sehr entgegenkommend.

Zitat

Hat da jemand seine Pillen noch nicht genommen?

im prinzip hab ich überhaupt keinen bock mehr pakete zu bauen. aber da kannst du nix dafür also sorry für offtopic.

Zitat

Geht es auch etwas freundlicher ?

90 % aller vdr entwickler sind gestört. ich hab mich nur angepasst

ob der VDR mit dem yaepg Patch gepatcht ist...wie erkennt ihr denn bei yavdr, ob dieser Patch aktiv ist?

der patch ist immer aktiv wenn er hier :

https://github.com/yavdr/vdr/b…ter/debian/patches/series

aktiviert wird. (# entfernen)
das heisst es gibt dafür keine defines weil es eine summe aus einzalptches gibt die eben in debian/series einzeln aktiviert werden können.

die patches liegen "einzeln" hier :
https://github.com/yavdr/vdr/tree/master/debian/patches

dadurch ist es einfacher die patches zu aktualisieren, als im "grossen" extensionspatch ...

wenn jetzt ein plugin aber ein ifdef dafür haben will, müsste ich sowas ja im makefile mitgeben. jetzt will ich das eben nicht patchen also gibt es für die pakete "make options" in debian/rules.
dort häng ich fest weil ich es nicht schaffe ohne fehler ein UE_YAEPG mitzugeben.
ist aber alles sehr paketbauspezifisch, da ich es nicht kann, muss es jemand anderes machen. solange bleibt es halt leider deaktiviert im paket. aber das dauert bestimmt nicht lange und lars oder gda haben die lösung.

nochmal ganz kurz offtopic und der unsitte mit den ifdefs :

Extension Patch fuer VDR 1.7.32

eben angesehen und schon 1 teilpatch gefunden den es so einzeln nicht mehr gibt und sich doch sehr gändert hat :
liemikuutio ist "alt" und es wurde ersetzt durch vdr-1.7.32-vasarajanauloja.patch

http://www.saunalahti.fi/~rahrenbe/vdr/patches/index.php

woher weiss jetzt ein plugin entwickler ob es sich um einen angepassten alten und evtl. fehlerhaften patch arbeite oder doch der neue ist ?
welcher in einer anderen distribution ist, aber dann nicht mehr funktioniert.... aber alles offtopic ich weiss.

holpo hat schon recht
die yavdr'ler haben ganz am anfang ganz klar gesagt das sie die pakete für sich bauen und das es support nur freiwillig in begrenztem Rahmen gibt

Aber durch yavdr kamen halt auch viele die sich nicht mit linux/vdr beschäfftigen wollen
und fordern andauernd irgend nen Mist

obwohl sie keinen anspruch darauf haben
die yavdr'ler haben keine Verträge unterschrieben oder ???

Zitat von louis

Im Plugin muss nichts gepatcht werden...ich prüfe über das USE_YAEPG nur, ob der VDR mit dem yaepg Patch gepatcht ist...wie erkennt ihr denn bei yavdr, ob dieser Patch aktiv ist? Ich kann die Abfrage dann auch dahingehend anpassen, habe ich keinen Stress mit.

Wenn du das über ein Define ermitteln willst, dann musst du selber dafür sorge tragen, dass dieses Define auch gesetzt wird. Und zwar in deinem Makefile. Um zum "Extension Patch" kompatibel zu bleiben, solltest du dessen Variablennamen nutzen. Also Prüfung auf "YAEPG = 1". So könnte man als Distributor dann so in Etwa in der Art bauen:

make YAEPG=1 VDRDIR=.... LOCALEDIR=... all

... und noch besser wäre es, wenn jemand mit diesem Problem an Klaus herantreten würde. Wenn Klaus an dem Feature kein Interesse hat, dann gehört etwas entsprechendes über die Service-Schnittstelle so eingebaut, dass interessierte Skins und Plugins direkt über diese Schnittstelle ein Ausgabe-Plugin, welches diesen Service anbietet, anweisen können, das Bild zu skalieren. Eine kurze Mail von jemandem, der sich mit den Hintergründen auskennt, würde ausreichen, um hier Klarheit zu schaffen wie man sowas sauber integrieren kann.

danke Mreimer
YAEPG=1 in debian/rules war genau das richtige.
ich versuch da die ganze zeit USE_YAEPG ... au mann ...

oder fehlt das noch im makefile beim plugin ?
naja mal testen.

Fehlt im Makefile beim Plugin...

louis

Du brauchst:

ifdef YAEPG
DEFINES += -DUSE_YAEPG
endif

an der richtigen Stelle. Also irgendwo zwischen Erst-Definition von "DEFINES" und eigentlichem Build-Vorgang.

Aber ich bitte an der Stelle nochmal darum, doch bitte mal Klaus zu kontaktieren. Ich würde es ja gerne tun, aber ich habe von den Hintergründen und der Funktion des Patches keine Ahnung. Wenn es auf eine Service-Schnittstelle hinausläuft wäre es zudem sinnvoll, wenn die von jemandem definiert wird, der die Schnittstelle letztlich auch nutzen muss...

jop Mreimer danke dir !

louis wow respekt das klappt hier auf meinem doppelatom völlig ruckelfrei.
aber ich hab hier das fadein und out auf 0 gesetzt. überall. sonst könnte man den eindruck haben es ruckelt

Zitat von Mreimer

Aber ich bitte an der Stelle nochmal darum, doch bitte mal Klaus zu kontaktieren. Ich würde es ja gerne tun, aber ich habe von den Hintergründen und der Funktion des Patches keine Ahnung. Wenn es auf eine Service-Schnittstelle hinausläuft wäre es zudem sinnvoll, wenn die von jemandem definiert wird, der die Schnittstelle letztlich auch nutzen muss...

Nur damit wir nicht alle redundanterweise damit los legen, bin gerade am Verfassen einer Nachricht für die VDR-Mailingliste, mal sehen wie Klaus sich dazu äußert.