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

  • lcdproc ist eine komplett andere baustelle.


    zwischen icons und text ist schon ein riesen unterschied (zumindest die wareagle icons, die ich kenne - die sind bilddateien).
    und dass es mit den icons zzt probleme gibt weiss ich.
    <variable name="bla" value="'{ConfigPath}/blalaber/fasel/{ChannelAlias}_l.glcd'"/>
    <image path="#bla"/>
    geht zzt nicht (da suche ich gerade).
    <image path="{ConfigPath}/blalaber/fasel/{ChannelAlias}_l.glcd" /> funktioniert (obwohl eigentlich nicht ganz korrekt notiert ohne ' ').


    gegenseitiges uebermalen der objekte:
    es gibt die farbe 'transparent', zumindest habe ich die mal definiert und implementiert (getestet aber schon lange nicht mehr).
    teste mal bitte mit bgcolor='transparent'.


    ich sehe, du hast ein weiteres problem bei den navibuttons. entw. wie gesagt transparent versuchen oder gleich das neue object 'button'.


    /wastl

  • lcdproc ist eine komplett andere baustelle.


    Wie meinst du das? Genauso wie graphlcd per serdisplib Ausgabeteiber serdispllib Displays nutzen kann, genauso kann lcdproc per graphlcd Ausgabetreiber graphlcd Displays (und damit dann auch serdispllib Displays) nutzen.
    Die Frage war ja nur ob es sinnig ist die lcdproc Leute mal über die Änderung der Schnittstelle zu Informieren oder ob es besser ist damit noch zu warten weil du evtl. Planst da kurzfristig nochmehr zu ändern? Nicht das ich da jetzt auf die Mailingliste Poste und morgen ist die Schnittstelle wieder komplett anderst, allerdings sollte man das auch mal zeitig sagen, sonst dauert es ja zu lange ehe das wieder geht.


    Und irgendwann wird der Touchcool Zweig ja auch mal das offizielle graphlcd Release, spätestens dann sollte IMHO der graphlcdproc Treiber wieder laufen. Und da muss dann ja schon mal jemand den Author drüber informieren (letzte Änderung ist letztes Jahr, also hat er da vermutlich noch Interesse am Projekt).


    zwischen icons und text ist schon ein riesen unterschied (zumindest die wareagle icons, die ich kenne - die sind bilddatein).


    Gibts da mehere Varianten? Beim 1.6er VDR und extrecnmenü wird einfach das Unicodezeichen X ausgegeben und erwartet das man nen Font hat der an dieser Stelle das Symbol enthält. Ist also kein Unterschied ob man jetzt das Zeichen "A" Ausgibt oder das Zeichen was aussieht wie ne Uhr.


    Keine Ahnung ob du das selber verwendest, http://andreas.vdr-developer.org/fonts/symbols.html



    OK, probiere ich beides mal.


    ich sehe, du hast ein weiteres problem bei den navibuttons. entw. wie gesagt transparent versuchen oder gleich das neue object 'button'.


    Ne das passt schon, da hatte ich nur noch nix dran gemacht.


    BTW:
    Wie erstellst Du den die tollen Screenshots von dem LCD?


    Für mein Display (SDC Megtron) liefert die serdisplib nen Kommmandozeilentool mit, mit dem man Screenshots vom Display ziehen kann.


    cu

  • ad lcdproc: ah ok. bekomme von lcdproc nur am rande mit. es gibt sogar, wenn ich mich richtig erinnere, eine direkte anbindung an meine library als contribution.
    aber der derzeitige fokus ist graphlcd / vdr-plugin-graphlcd. und da ist in der tat nix wirklich fix.


    ad vdr-eigene fonts: auch das ist wohl an mir vorbei gegangen. muss ich mal testen. aber wenns nicht funktioniert heisst das wohl, dass die UTF8-unterstuetzung defekt ist :(

  • > es gibt sogar, wenn ich mich richtig erinnere, eine direkte anbindung an meine library als contribution.


    Mit deiner Library meinst du serdisplib? In der Tat, gerade mal gegooled und nen Patch in ner Mallingliste gefunden, aber ins
    Projekt hat es der Treiber anscheinend nicht geschaft. Dann setze ich das mal auf meine ToDo Liste das mal auszuprobieren. Danke für den Hinweis. Wenn das klappt wäre ich den Umweg über graphlcd-base dort los.


    Tja, das Forum... Anmelden geht bei mir eigentlich immer, nur das Zitieren klappt garde nicht, selbst dann nicht wenn ich JavaScipt ausschalte (das hilft meistens). So ritig Opera freundlich ist das Forum anscheinend auch nicht.


    cu

  • ja leck, das war jetzt eine schwere geburt. mit vielen printf-debug anweisungen ...


    der fehler mit den imagepfaden, in dem tokenangaben wie {ConfigPath}, ... enthalten sind, sollte jetzt behoben sein.
    bitte testen.


    dann kann ich mich ja mal an den plan machen, lesenden zugriff auf imagemagick-unterstuetzte formate zu implementieren (MNG!) bzw. den code dazu von text2skin zu stehlen ...
    graphlcd-base ist zwar dann bei bedarf abhaengig v. imagemagick (werde es nicht standardmaessig aktivieren), aber dann koennen die channellogos v. text2skin verwendet werden (so der plan). in farbe und bunt.


    /wastl

  • der erste schnellpfusch in sachen imagemagick funktioniert bereits (noch nicht ganz brauchbar (orf-logo ist zb. gedithered obwohl es das nicht soll)), aber das logo ist zumindest schon in farbe zu sehen. gibts irgendwo animierte senderlogos fuer text2skin? die sollten eigentlich auch aus dem stand funktionieren jetzt ...


    /wastl


    anmerkung: die bilder sind mit libsdl-ausgabe erstellt (da muss ich nicht fotografieren), aber mit derselben aufloesung (320x240) wie l4m320t.


    EDIT:
    dithering problem war gar keines. das standard orf1-logo war schon so. das alternativlogo sieht hingegen brauchbar aus.


    das zeug ist auch bereits committed.
    wenn man es testen will muss man im glcdgraphics/Makefile die variable IMAGELIB setzen:

    Code
    1. IMAGELIB = imagemagick

    oder statt imagemagick sollte auch graphicsmagick funktionieren.

  • Da bin ich mit meinen kontrastschwachen Weis/Blau LCD ja fast neidisch :)


    Wo gibts das Display denn überhaupt? Weil, TFT mit Touch perUSB, das hört sich ja richtig gut an.


    BTW: Das mit den Pfaden funktioniert jetzt bei mir.


    cu

  • anmerkung: die bilder sind mit libsdl-ausgabe erstellt


    Und wie genau macht man das?
    Und wie sage ich nun graphlcd, dass farbige Bilder verwendet werden sollen? Und welches Format sollen die Logos haben?


    Fragen über Fragen.. :)


    Schon wäre auch, wenn Du das Makefile von:

    Code
    1. IMAGELIB =


    ändern könntest in:

    Code
    1. # IMAGELIB = imagemagick


    Dann geht es leichter, ein ebuild zu erstellen. ;)


    Wo gibts das Display denn überhaupt? Weil, TFT mit Touch perUSB, das hört sich ja richtig gut an.


    Gibt es bei L4M.
    Am besten Du schreíbst Bernhard eine Mail.

  • gar nicht. dieser branch verwendet von haus aus intern 32bit pro pixel. egal ob farbdisplay, monochrome oder greyscale. dh auch die bw-formate wie glcd werden intern auf 32bit / pixel umgerechnet (es werden halt nur 2 verschiedene farben verwendet ...).


    unterstuetzte formate: die, die graphlcd bis jetzt schon konnte (glcd, pbm) und mit imagemagick-support halt alles, was imagemagick unterstuetzt (theor. sollten sogar anim gifs funktionieren - aber noch nicht getestet).


    makefile: haette ich eigentlich oben geschrieben, wieso ich das so voreinstelle...
    ev. werde ich eine abfrage noch einbauen, ob im vdr-eigenen Make.config (das ja, wenn vorhanden, inludiert wird) bereits imagemagick aktiviert wird, aber ansonsten bleibt es einstweilen wie es ist.


    ad fix-und-fertig packages: das ganze ist zzt sehr experimentell. weiss nicht, ob es klug ist, packages davon in die freie wildbahn (ie. auf nicht auf diesen branch eingearbeitete benutzer) loszulassen.


    /wastl

  • makefile: haette ich eigentlich oben geschrieben, wieso ich das so voreinstelle...


    Eben! Deshshalb habe ich ja nach:


    # IMAGELIB = imagemagick


    gefragt.


    Kann es sein, dass dein Browser nicht nur ein Login-Problem hat, sondern auch nicht alles anzeigt?? - Oder sind meine Fragen einfach nur zu trivial, um darauf nicht zu antworten? :lol2

  • das # habe ich ueberlesen, die logik verstehe ich trotzdem nicht.
    was macht ein
    # bla = laber
    besser als ein
    bla =
    ? kommt genau auf dasselbe heraus?!


    eine zeile drueber steht eh erklaert, was man da reingeben kann?
    # External image lib to use: imagemagick, graphicsmagick, or none


    aber ich kann schon alle moeglichen varianten auskommentiert hineinschreiben wenns besser gefaellt.

  • PNG Lesen klappt gut (endlich nen richtigen Gafikformat :) ) Animierte GIFs gehen auch.


    Allerdings lasse ich die Logos invertiert darstellen, bissher ging das natürlich, aber bei PNG werden sie immer gemäss den Farben dargestellt wie sie im Bild gespeichert sind. Ist ja auch erstmal logisch, und die erste Lösung wäre es die Logos halt selber zu invertieren, kein Problem, aber dann müssen wir generll vom "ein Logo Verzeichnis für alle Skins" Ansatz weggehen und jeder Skin hat sein eigenes Logo Verzeichis. Könnte man da beim Image Tag noch nen Invert zufügen?


    Deweiteren, das mit dem nur die Displaybereiche updaten die notwendig sind... Nachdem man es per SVDRP wieder angeschaltet hat sollte ein Komplettupdate erfolgen, ansonsten baut sich das nur sehr mühsam wieder auf ;)


    BTW: Keine Ahnung obs so gedacht, einfach noch nicht eingebaut oer nen Fehler ist. Bei 8 Bit Paletten PNG wird die transparente Farbe ignoriert, und alle Farben ausser B/W werden ignoriert, also kein Dithering (würde sich z.B für Grautöne anbieten). Ist jetzt nicht so das Problem, es sollte nurmal festgelegt werden obs so sein soll oder nicht.


    BTW2: "transparent" als Farbe zum Rechteck Objekt geht auch nicht


    BTW3: Das convpic Tool mag mit meine animierten glcd nicht zurückkonvertieren. Bei den erzeugten BMP sind generell alle Pixel schwarz. Aber das nur nebenbei, hab meine glcd jetzt per HEX Editor convertiert und bin von glcd weg.


    cu

  • cool dass anim gifs funktionieren. muss ich fast mal ausprobieren :)
    ev. beschraenke ich aber die max. anzahl von unterstuetzten frames auf 50 oder so. sonst kann man mit einem falschen anim gif den vdr mit anlauf in den graben fahren :) oder eine groessenbeschraenkung (aufloesung). da ist zzt. ueberhaupt nichts dergleichen implementiert von mir ...


    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?


    ganzes display updaten nach SVDRP on: thx fuer den hinweis. das sollte aber eine kleinigkeit sein zu fixen.


    ad btw2: aha? muss ich mir anschauen. thx fuer den hinweis.
    ad btw3: habe ich eingangs erwaehnt, dass die ganzen conv-tools noch nicht funktionieren werden (da ich mich bis jetzt nur um die lade-, nicht aber um die speichermethoden gekuemmert habe.


    die naechsten tests werde ich mit dem sdc-megatron machen. kannst du - falls sich in der zwischenzeit etwas daran geaendert hat - dein aktuelles skin-file hier noch mal zur verfuegung stellen?


    @C-3P0:
    verstehe deshalb aber immer noch nicht, was da dann eine auskommentierte zeile fuer einen vorteil darstellt!?


    aber wie bereits geschrieben will ich das ohnedies ueber eine abfrage eines defines (das zb. im vdr-eigenen Make.config gesetzt ist) auswerten. das sollte sich dann auch von aussen (distro-unabhaengig) steuern lassen.


    zu der einen frage in einem vorigen posting: das muss ich mir noch ansehen, wie das sauber geht (da gibts defines (a la prefix, exec_prefix), die fuer gewoehnlich da verwendet werden - unix/distro-uebergreifend). das habe ich wohl uebersehen. thx jdnfalls fuer den hinweis.


    /wastl

  • @C-3P0:
    verstehe deshalb aber immer noch nicht, was da dann eine auskommentierte zeile fuer einen vorteil darstellt!?


    Nun, da Du es so oder so noch ändern willst, hat sich das ja erstmal erledigt. ;)


    anmerkung: die bilder sind mit libsdl-ausgabe erstellt (da muss ich nicht fotografieren), aber mit derselben aufloesung (320x240) wie l4m320t.


    Allerdings habe ich immernoch nicht begriffen, wie ich solche Screenshots erstellen kann... :(


    Auch ein kleines Howto zum Thema "Farbige Channellogos" wäre nicht schlecht. :]

  • farbige channellogos: einfach statt glcd-files andere logos verwenden? (zb. v. text2skin). es bedarf keiner weiteren anpassungen.
    dh zum beispiel statt vorher:
    <variable id="ChannelLogo" value="'{ConfigPath}/logos/channels/{ChannelAlias}_l.glcd'"/>
    jetzt
    <variable id="ChannelLogo" value="'{ConfigPath}/collogos/{ChannelAlias}.mng'"/>
    mehr ist es nicht.


    libsdl:
    serdisplib kann seit einiger zeit auch in ein SDL-ausgabefenster ausgeben. siehe auch: http://serdisplib.sourceforge.net/ser/out_sdl.html
    (das --enable-libsdl wird bei 1.98 nicht mehr benoetigt).


    screenshots dann einfach mit ksnapshot erzeugt (vom sdl-fenster).

  • farbige channellogos: einfach statt glcd-files andere logos verwenden? (zb. v. text2skin). es bedarf keiner weiteren anpassungen.
    dh zum beispiel statt vorher:
    <variable id="ChannelLogo" value="'{ConfigPath}/logos/channels/{ChannelAlias}_l.glcd'"/>
    jetzt
    <variable id="ChannelLogo" value="'{ConfigPath}/collogos/{ChannelAlias}.mng'"/>
    mehr ist es nicht.


    Funktioniert bei mir leider nicht. :(


    Ich habe die Logos mit 64x48 im *.nmg Format vorliegen, aber leder habe ich nur ein schwarzes Fensterchen.


    Code
    1. <variable id="LogoW" value="64"/>
    2. <variable id="LogoH" value="48"/>
    3. <variable id="LogoX" value="mul(-1,#LogoW)"/>
    4. <variable id="ChannelLogo" value="'{ConfigPath}/logos/channels/color/{ChannelAlias}.mng"/>


    {ChannelAlias} <-- Das ist doch der Name, wie er in der channels.conf steht, oder??