graphlcd (base, vdr-plugin) touchcol branch (archiv)

  • Gibt leider kein imagemagick zurück, obwohl ich es im makefile angegeben habe.


    Code
    1. vdr01 ~ # ldd /usr/lib/libglcdgraphics.so
    2. linux-gate.so.1 => (0xffffe000)
    3. libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb76a3000)
    4. libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.5.2/libstdc++.so.6 (0xb75b4000)
    5. libm.so.6 => /lib/libm.so.6 (0xb758f000)
    6. libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.5.2/libgcc_s.so.1 (0xb7574000)
    7. libc.so.6 => /lib/libc.so.6 (0xb742a000)
    8. libz.so.1 => /lib/libz.so.1 (0xb7415000)
    9. /lib/ld-linux.so.2 (0xb7769000)
    10. vdr01 ~ #
  • Nun, da ich via ebuild installiere, Patche ich das Makefile erst kurz vor "make" mit diesem Patch:



    Siehe: -->


    Code
    1. .....
    2. >>> Unpacked to /tmp/portage/app-misc/graphlcd-base-9999/work/graphlcd-base-9999
    3. [32;01m*[0m Applying imagemagick.diff ...
    4. .....


    So sieht das ebuild aus: --> http://paste.pocoo.org/show/385437


    Infos zu gcc:


    Code
    1. vdr01 ~ # gcc -v
    2. Es werden eingebaute Spezifikationen verwendet.
    3. COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.5.2/gcc
    4. COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.5.2/lto-wrapper
    5. Ziel: i686-pc-linux-gnu
    6. Konfiguriert mit: /tmp/portage/sys-devel/gcc-4.5.2/work/gcc-4.5.2/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.5.2 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.5.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.5.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.5.2/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --disable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.5.2/python --enable-checking=release --disable-libgcj --with-arch=i686 --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.2 p1.1, pie-0.4.5'
    7. Thread-Modell: posix
    8. gcc-Version 4.5.2 (Gentoo 4.5.2 p1.1, pie-0.4.5)
    9. vdr01 ~ #
  • logos invertiert / gedithered:
    ist alles noch nicht beruecksichtigt. dithering soll natuerlich ebenfalls kommen (entw. ueber das imagemagick-eigene dithering oder ich klopfe mal schnell den floyd-steinberg-algo hinein (den sourcecode brauche ich nur von meiner lib uebernehmen).
    das mit der transparenz bei PNGs/GIFs wird aber ev. einen kleinen eingriff in die image-basisklasse beduerfen. mal schauen.
    der jetzige stand ist einfach nur: funktionierts und sehe ich bildchen in farbe und bunt?


    Ich bin gerade dabei den Skin farbtauglich zumachen. Keine Ahnung ob was bringt da er nur auf 240x128 läuft, aber egal, evtl. mag den jemand als Vorlage nutzen oder es gibt evtl. sogar Farbdisplays mit dieser Auflösung.


    Aus dieser Erfahrung raus denke ich:
    - Es wäre sinnig wenn man generell eine Hintergrunffarbe definieren könnte mit der die Flächer erstmal gefüllt wird (man kann zwar auch nen rEchteck malen, aber wäre so irgendwie schlüssiger).
    - Alle Objekte per DEfault nen transparenten Hintergrund hätten.
    - Es die Möglichkeit gäbe 1BPP Images (Nur da macht es Sinn) zu Invertieren und hier beim Image Tag Vordergrund und Hintergrundfarbe angeben zu können (z.B. Sinnig für 1BPP Logos auf nem Farbdisplay). Das funktioniert ja jetzt schon mit glcd Images so. Ferner wäre es schön hier auch die transparente Farbe (gibts ja auch bei 1BPP zusätzlich) mit auszuwerten.



    Ich lade meinen skin morgen mal hoch. Wäre dann auch schön wenn du ihn dann auch mal auf deinen Farbdisplay laufen lassen würdest (der klebt dann in 240x128 oben links, zum schauen wies aussieht sollte das aber reichen).


    cu



    cu

  • die ideen zu den bildern / invertieren / ... sammle ich, werde, so es moeglich und einfach realisierbar ist, diese auch der reihe nach einfliessen lassen. aber gerade das mit transparenz ist nicht ganz so einfach wenn ich mich richtig erinnere (ist schon lange her dass ich das damals eingebaut habe - habe vor ein paar tagen ja nach langer zeit wieder das ganze zeug fortgesetzt).


    btw: invertieren wuerde auch bei greyscale-displays sinn machen.


    zu deinem geplanten farbskin: vielleicht gleich so erstellen, dass er sich auch auf groessere displays ausbreitet ({ScreenWidth}, {ScreenHeight} und andere nette dinge fuer relative positionsfestlegung).


    aber wieder die obligatorische branch-warnung: alles fliesst - alles ist im wandel ... (unter der (arbeits-)woche wohl wieder zaehfluessiger ...)

  • @C-3P0
    jedenfalls kommt lt. log nichts vom ifeq ($(IMAGELIB), .... else ifeq ... endif zum zug. weil sonst muesste bei den c-files in glcdgraphics -DHAVE_IMAGEMAGICK und -I/path_to_imagemagick dabeistehen beim kompilieren. ist irgendein sonderzeichen oder so hineingerutscht in dein diff, oder spinnt der ifeq-abschnitt in deiner umgebung? (habe es 1:1 aus text2skin gestoh... aeh uebernommen ...).


    haenge mal das gepatchte Makefile hier als attachment herein (nicht ueber das paste.pocoo-zeug).

  • die ideen zu den bildern / invertieren / ... sammle ich, werde, so es moeglich und einfach realisierbar ist, diese auch der reihe nach einfliessen lassen. aber gerade das mit transparenz ist nicht ganz so einfach wenn ich mich richtig erinnere (ist schon lange her dass ich das damals eingebaut habe - habe vor ein paar tagen ja nach langer zeit wieder das ganze zeug fortgesetzt).


    Wobei die Transparenz eigentlich bei 1BPP gar nicht so wichtig ist wenn man als Hintergrundfarbe im Image Tag die gewünschte Hintergrundfarbe angibt. Dann dürfen sich halt Bilder nicht überlagern, aber wann kommt das schonmal vor?


    Ist dann halt nur die Frage für die Farbigen Senderlogos. Wenn man für seinen Blauen Hintergrund das Logoset mit Logos mit weissen Hintergrund hat... Wobei, wen die Antiaias auf weiss machen sieht das mit der ner anderen Hintergrunsfarbe auch blöd aus, da braucht man dann antialias mit nem Alphakanal. Kann wirklich kompleziert werden wenn man erstmal anfängt da drüber nachzudenken ;)


    btw: invertieren wuerde auch bei greyscale displays sinn machen.


    Stimmt.
    BTW: kann der Skion auch querryFeature('isgreyscale')? Weil unterschiedliche Farbdefinitionen für Fabe und Graustufen macht Sinn.



    zu deinem geplanten farbskin: vielleicht gleich so erstellen, dass er sich auch auf groessere displays ausbreitet ({ScreenWidth}, {ScreenHeight} und andere nette dinge fuer relative positionsfestlegung).


    Nein, das möchte ich bewusst nicht tun. Denn IMHO ist das immer ein Kompromiss der niemals wirklich befriedigend ist. Ich mache bei mir extrem Pixelpositionierung weil ich da wirklich möchte das sich das perfekt (IMHO natürlich) aufteilt.


    Und die Idee ist das das den einer von vielen im Packet ist. Entweder der gefällt jemanden mit passenden Display oder jemand mit nem Display in anderer Auflösung gefällt er und nimmt ihn um eine Variante für seine Auflösung zu erstellen.


    cu

  • @3-CP0


    jetzt weiss ich auch, wieso du so versessen auf das # IMAGELIB warst: sed-kenntnisse nur fuer einfache dinge. mit reg.expressions geht das ganze aber auch eleganter und auch noch ohne herumgepatche:


    Code
    1. sed -i "s/^IMAGELIB\ =\s*$/IMAGELIB\ =\ imagemagick/" Makefile


    oder (wenn graphicsmagick gefragt ist):


    Code
    1. sed -i "s/^IMAGELIB\ =\s*$/IMAGELIB\ =\ graphicsmagick/" Makefile


    ersetzt ein
    IMAGELIB =
    durch etwas anderes (und zwar nur, wenn es am anfang der zeile vorkommt und nach dem = nichts oder ausschliesslich leerzeichen (bzw. white-spaces) sind)

  • Nur mal schnell notiert weils mir gerade aufgefallen ist. Die Option "skinspath" wird in der Commandlinehelp der Plugins nicht erwähnt.


    cu

  • Ich hätte da mal eine Verständnisfrage zu "{ChannelAlias}.":


    Wenn ich ein festes Bild setze:

    Code
    1. <variable id="ChannelLogo" value="'{ConfigPath}/logos/channels/color/ORF1.mng'"/>


    Dann wir es angezeigt.
    Wenn ich aber

    Code
    1. <variable id="ChannelLogo" value="'{ConfigPath}/logos/channels/color/{ChannelAlias}.mng'"/>


    setze, dann nicht.


    Die *.mng Files heißen genauso, wie der Sendername in der channels.conf.


    Was mache ich denn falsch??

  • ausschlaggebend dafuer ist channels.alias. nicht der channel-name, sondern diese komische ID ist relevant!


    damit habe ich auch ein wenig gekaempft - noch dazu wo ich mit dvb-t arbeite). aber da gibt es irgendwo im forum ein script, das aus einer bestehenden channels.conf den passenden inhalt fuer channels.alias generiert. und da kann man dann noch nachjustieren (gross/kleinschreibung, spaces, ...)

  • {ChannelAlias} mappt den Namen ja noch über die Alias Datei. Was steht denn da drin?


    Du kannst auch {ChannelName} nehmen wenn die Bilder nach dem Sendernamen benannt sind.


    cu

  • wobei ich den channelname nicht verwenden wuerde. der wechselt ja manchesmal oefter als so mancher seine unterhose ... (ganz leicht ueberspitzt gesagt).
    und dann gibts dvb-c provider, die bei einigen channel-names ein "* " davorknallen, etc. ...
    da sollte die zuordnungstabelle in channels.alias konstanter bleiben :)