[ANNOUNCE] graphlcd 0.1.9

  • Hört sich alles sehr interessant an.


    Ich warte mal ab, bis das mit dem "Mixed" funktioniert und dann teste ich das mal.


    Einzige Frage, die noch offen ist, wäre halt, in wiefern das mit dem geplanten allgemeinen Theme-System harmoniert.

  • Quote

    Originally posted by Mreimer
    Einzige Frage, die noch offen ist, wäre halt, in wiefern das mit dem geplanten allgemeinen Theme-System harmoniert.


    Naja, es gibt ja im Prinzip nur zwei Möglichkeiten.


    1. Das Theme malt selber. Im Prinzip das selbe wie die Empfangsquallitätsbalken über die Daten des femon-Plugion.
    Hier gibts dann halt die Visualisirungsbalken über die Daten des SPAN Plugin.


    2. Es gibt ein neues Theme Objekt indem ein Bereich festgelegt wird welches vom Plugin selber verwaltet wird. Also so was in der Art

    Code
    1. <plugin x1="10" x2="10" width="100" height="100" source="span" style="simple" />

    Und dann sorgt das Plugin halt selber dafür das da was hübsches reingemalt wird solange das Objekt dargestellt wird.



    Ich wäre für Variante 2, denn Variante 1 kann mit dem text2skin Syntax echt komplex werden. Das wäre in der Praxis vermutlich nicht wirklich brauchbar.


    cu

  • Quote

    Ich warte mal ab, bis das mit dem "Mixed" funktioniert und dann teste ich das mal.


    Sorry , nachdem ich das schon 2 x geschrieben habe was der Patch macht und kann
    muss ich einfach mal schreiben , Code anschauen und verstehen sind wohl 2 paar
    Sachen ;)
    Ich wiederhole das jetzt nun nicht "nochmal".



    Quote

    Ich wäre für Variante 2, denn Variante 1 kann mit dem text2skin Syntax echt komplex werden. Das wäre in der Praxis vermutlich nicht wirklich brauchbar.


    Durch den Patch passiert genau dass , was mit Skin-Support passieren wuerde.
    Nen Skin kann auch garnet selber zeichnen , ansonsten braeuchte es das graphlcd Plugin nicht , weil genau das das Plugin macht ;)
    ..und nebenbei ob 1. oder 2. Methode waere Jacke die Hose...


    Wenn da bei Skinsupport etwas komplex wird , dann hat da jemand was falsch gemacht.
    Kann man sich doch selber vorstellen was man bei den geringen Pixelgroessen Tolles mit
    Skins anstellen kann ;)


    nix fuer ungut...

  • Quote

    Originally posted by Morone
    Durch den Patch passiert genau dass , was mit Skin-Support passieren wuerde.


    ?


    Quote

    Originally posted by Morone
    Nen Skin kann auch garnet selber zeichnen , ansonsten braeuchte es das graphlcd Plugin nicht , weil genau das das Plugin macht ;)
    ..und nebenbei ob 1. oder 2. Methode waere Jacke die Hose...


    Wir reden hier so was von aneinander vorbei ;)


    Quote

    Originally posted by Morone
    Wenn da bei Skinsupport etwas komplex wird , dann hat da jemand was falsch gemacht.


    Aber so was von ;)


    Evtl. schau ich mir mal deinen Patch an und du dir die Skin Sache, dann klappt die Kommunikation evtl. ;)


    cu

  • Quote

    Evtl. schau ich mir mal deinen Patch an und du dir die Skin Sache, dann klappt die Kommunikation evtl.


    Mir waere lieber , wenn du das in kurzen Worten erklaeren wuerdest oder nen Link rueberreichst ,
    dann muesste ich mir da nix zusammensuchen.
    Das Interesse an Skinfaehigkeit bei nem 140 x 32 VFD haelt sich hier doch stark in Grenzen ;)
    Da lasse ich ich die Abspielzeit , Progressbar und Titel anzeigen und habe genau noch
    6 Pixel oben Platz.


    So , ich habe im Wiki was davon gelesen (zb dasses noch net public ist ;)) auch wenn ich
    mir vorher schon was drunter vorstellen konnte.
    Dachte nur da kommt was anderes aber so bleibt meine Aussage halt bestehen.

  • Quote

    Originally posted by Morone


    Mir waere lieber , wenn du das in kurzen Worten erklaeren wuerdest oder nen Link rueberreichst ,
    dann muesste ich mir da nix zusammensuchen.


    Naja, im Prinzip ist das Text2Skin.


    Und da gibts eigentlich zwei Möglichkeiten. Du malst die Visualisierung selber. So in der Art


    Das malt denn das angehängte (oben Rechts, wechselt mit dem Logo).
    Nach dem selben System (Visualisierung ist im einfachsten Fall ja auch nur Balken, für mehr brauchts neue Malfunktionen) müsste man dann auch die Visualisierung malen. Alternativ halt Vorschlag 2. Und Vorschlag 2 fände ich da halt sinnvoller.


    Quote

    Originally posted by Morone
    Das Interesse an Skinfaehigkeit bei nem 140 x 32 VFD haelt sich hier doch stark in Grenzen ;)


    Das Interesse an ner Version ohne Skin Support hält sich bei mir stark in grenzen ;) Hab 240x128 LCD, und ohne Skin sehe ich da nur kleine Flecken (soll wohl Text sein) und viel verschwendeten Platz ;)


    Ich meine, du musst ja nicht. Scheint mir nur irgendwie Zeitverschwendung wenn du da jetzt viel investierst und das dann alles wieder mit dem nächsten Release rausfliegt.


    Quote

    Originally posted by Morone
    So , ich habe im Wiki was davon gelesen (zb dasses noch net public ist ;))


    Ist im GIT im 0.2.0er Branch. Publicer gehts nicht.


    cu

  • Ja , soweit habe ich das schon verstanden aber ich verstehe jetzt dein Anliegen net ;)
    Aber wenn ich das richtig verstehe bedeutet dein Vorschlag 2 ja , dass das GLCD Plugin vom Skin ne Flaeche zugestimmt bekommt , womit es machen kann was es will.
    Aber wo liegt denn da der Sinn und wo ist das komplex , wenn der Skin sagt was und
    wie und wofuer der Platz genutzt werden soll , DAS ist doch der Sinn an so nem
    Skinsupport.


    Text2Skin ist doch auch nur nen Loader fuer irgendwelche Werte . Im verinefachten Sinn habe ich doch nix anderes gemacht.
    Zeichnen muss das GLCD-Plugin ja immer noch selber , genauso wie VDR mfur Text2Skin.. :confused..so akku gleich leer.. ;)

  • Quote

    Originally posted by Morone
    Ja , soweit habe ich das schon verstanden aber ich verstehe jetzt dein Anliegen net ;)


    Weil es auch gar nicht an dich gerichtet war ;) Mreimer fragte wie das wohl mit den Skins zusammenpasst, und da schrieb ich welche zwei Möglichkeiten es gibt. Einfach nur mal so.


    Quote

    Originally posted by Morone
    Aber wenn ich das richtig verstehe bedeutet dein Vorschlag 2 ja , dass das GLCD Plugin vom Skin ne Flaeche zugestimmt bekommt , womit es machen kann was es will.


    Jup.


    Quote

    Originally posted by Morone
    Aber wo liegt denn da der Sinn


    Wie würdest du es machen?


    Quote

    Originally posted by Morone
    und wo ist das komplex , wenn der Skin sagt was und
    wie und wofuer der Platz genutzt werden soll


    Ebend, deswegen sagte ich Variante 1 ist komplex, Variante 2 ist es nicht.


    cu

  • mal meine ueberlegungen, die ich diesbez. angestellt hatte, kundtun:


    eines der probleme ist, dass beim glcd 0.2.x-zeug die skinfuntionalitaet in der base und _nicht_ im graphlcd-plugin selber enthalten ist. das macht das ganze etwas - uhm - spannend (nett formuliert).
    waere es teil v. plugin, waere manches vielleicht einfacher. dafuer kann man vom base andere nicht-vdr-programme ableiten, die dann skinbar sind. das ist dann eine abwaegungssache. wenns mich mal zu sehr nervt, werde ich das skin-zeug zum plugin schieben.


    zum span: habe das mit meinen zwei installationen zwar noch nie zum laufen bekommen, aber theoretische ueberlegungen habe ich dazu: beim span-plugin koennen die werte ja als zahlenreihe abgeholt werden (nach vorheriger initialisierung ebenfalls mit ein paar zahlenwerten (wenn ich mich richtig erinnere)). die skinfunktionalitaet (die von einem service 'span' dann bescheid weiss und das vorhandensein entsprechend mit IsServiceAvailable() abpruefen kann) setzt diese zahlenwerte dann entsprechend um. das koennte dann sogar so weit gehen, dass das ganze bei einem farbdisplay entsprechend aufbereitet wird: niedriger ausschlag: gruen bis hin zu gruen + orange + rot : hoher ausschlag. mal irgendwann wieder mit span herumspielen ...


    zum fortschritt v. 0.2.x: da steht leider zur zeit alles still (zeitmangel, ausserdem habe ich keinen brauchbaren/funktionierenden VDR mehr (keine smartcard mehr fuer den dvb-c empfang - die hat jetzt der fernseher). aber ich werde den dvb-t stick ausgraben, damit ich zumindest einen VDR fuer die weiterentwicklung habe (ein paar sender habe ich auch damit und auch EPG - das sollte ausreichen fuer die entwicklung).


    /wastl

  • Quote

    Wie würdest du es machen?


    Wenn ich mich zwischen deinen beiden Vorschlaegen entscheiden muesste, dann ganz
    klar Vorschlag 1.
    Wo liegt da der Sinnn , wenn ich Skinsupport bereitstelle und im Nachhinein legt das Plugin wieder selber fest wo, wie , was gezeichnet wird.


    Quote

    Ebend, deswegen sagte ich Variante 1 ist komplex, Variante 2 ist es nicht.


    Ja und ich sage dir , es ist Jacke die Hose ;)
    Du brauchst Werte(skin) wo und wie was angezeigt wird , Daten vom Span-Plugin und ne
    Ausgabe (glcd/osd/whatever)
    Ist dir Vorschlag 2 lieber , funzt mein Patch fast outof box.
    Ist dir Vorschlag 1 lieber , passt du halt die Parameter an den Skinsupport an.
    Letztendlich passiert mit dem Patch nix anderes...
    Aber wir diskutieren ueber "Peanuts" also was solls ;)

  • Hi,


    kann es denn sein, dass sowohl graphlcd-base-0.1.9 als auch vdr-graphlcd-0.1.9 noch nicht wirklich UTF-8 fähig sind?
    Ich verwende TTF Fonts, und zwar VDRSymbolsSans.ttf welche im VDR-OSD auf meinem UTF-8 System nicht nur Umlaute und zum Beispiel rumänische diacritics gleichzeitig korrekt anzeigt, sondern auch noch diese coolen VDR-Symbole in der Aufnahmeliste oder Timerliste bringt.


    Wenn man nun VDR erstmal aussen vor lässt und mit graphlcd-base-0.1.9 folgendes probiert (ignoriert mal die falschcen Zeichen in der Code-Formatierung des Forums):

    Code
    1. showtext --config /etc/graphlcd.conf --encoding utf8 --display image --font ft2:/usr/share/fonts/vdrsymbols-ttf/VDRSymbolsSans.ttf:22 "Ââc_^bÂÎ" "öäüßÜÄÖ" "ýýýýýýýýýýýý" "ýýýýýýýýýýý"

    kommt das dabei heraus:
    [Blocked Image: http://www.muresan.de/graphlcd/vdrportal/showtext_VDRSymbols.png]


    Wenn ich graphlcd-base-0.1.9 mit dem angehängten Patch graphlcd-base-0.1.9_utf8_v3.diff baue, sieht das gleiche nochmal dann so aus (und zwar wie es sollte):
    [Blocked Image: http://www.muresan.de/graphlcd/vdrportal/showtext_VDRSymbols_utf8-v3.png]


    Nun zu VDR. Egal, ob ich graphlcd-base patche oder nicht, werden nur deutsche Umlaute im graphlcd Display korrekt angezeigt (weil offenbar die zufälligerweise auch mit ISO-8859-1 passen, siehe nachfolgend erwähnten Patch), rumänische diacritics oder gar diese VDR Symbole landen als doppelte oder dreifache Fragezeichen auf dem Display. Mit dem angehängten Patch vdr-graphlcd-0.1.9_utf8.diff werden auch die rumänischen diacritics korrekt gerendert, die VDR-Symbole leider immer noch nicht.


    Hat irgendwer eine Idee, was da falsch läuft? Sind diese Patches sofern "aufnahmewürdig"?


    Cu,
    Lucian

    Files


    8)


    Gentoo overlay mit VDR (und nicht nur) ebuilds, vdrcm, GLCDprocDriver

    The post was edited 2 times, last by Zoolook ().

  • Hallo,


    eben ist mir aufgefallen, dass in der Kopfzeile meines GLCD der Monat März nicht korrekt als 'Mär' angezeigt wird, sondern in UTF8-Hieroglyphen. Dazu habe ich bei mir nachfolgenden fix vorgenommen:


    in Datei 'display.c' (Git-Stand) habe ich die Zeile 791 von

    Code
    1. snprintf(buffer, sizeof(buffer), "%s %2d.%s %d:%02d", (const char *) WeekDayName(tm->tm_wday), tm->tm_mday, month, tm->tm_hour, tm->tm_min);

    in

    Code
    1. snprintf(buffer, sizeof(buffer), "%s %2d.%s %d:%02d", (const char *) WeekDayName(tm->tm_wday), tm->tm_mday, Convert(month), tm->tm_hour, tm->tm_min);


    abgeändert. Jetzt funktioniert es korrekt. Könnte das bitte jemand in den Git übernehmen!?


    Danke, Gruss Steve135


    P.S.: Sorry das ich kein diff geliefert habe, aber ich habe gerade schon soviel an meinen plugin-Quellen gebastelt, dass ein korrektes, zum Git passendes diff momentan nicht so einfach zu erstellen ist.


    [Edit]
    Bug #599 im Bug-tracker erstellt.

  • Quote

    Original von FireFly
    Die Patches Zoolook kommen mir (in Teilen) von graphlcd-0.1.8 bekannt vor - waren die doch nicht notwendig für UTF8?


    Doch, sogar schon etwa seit 0.1.5 oder 0.1.6 mindestens. Die Teil mit der Code-Konversion hatte ich mal hier im Portal gefunden, aber noch wegen damals recht vielen bugs noch selber um diesen bitmap cache erweitert.


    8)


    Gentoo overlay mit VDR (und nicht nur) ebuilds, vdrcm, GLCDprocDriver

  • Quote

    Original von FireFly
    Deshalb wundert es mich ja, dass sie nicht in 0.1.8/0.1.9 drin sind, obwohl die ja UTF8-fähig sein sollen - oder habe ich da was falsch verstanden?


    Nun, ich bin auch verwundert, wieso die für UTF8-fähig erklärt wurden. Die ganze Konfusion dauert schon seit Version 0.1.6 an, da hatte ursprünglich Trantor einen Patch, dann hatte ihn DarkMike verbessert, ich hatte mich damals vor einem Jahr noch bemüht, die notwendigen Patches aufzuzählen, aber zu dem Zeitpunkt etwa vor einem Jahr, ging ja dieser Skins Hype los, der in jedem graphlcd Thread, auch noch so "0.2.0"-fremd breitgetreten wird...


    8)


    Gentoo overlay mit VDR (und nicht nur) ebuilds, vdrcm, GLCDprocDriver

  • Quote

    Original von Zoolook


    Nun, ich bin auch verwundert, wieso die für UTF8-fähig erklärt wurden.


    ich verwende auf keinen meiner maschinen UTF-8, d.h. ich seh natuerlich solche sachen nicht selber;
    da brauch ich schon hinweise von den usern, die sowas nutzen ;)


    wie kann ich denn am einfachsten die fehler nachstellen? der beispielscreen von zoolook sieht mir
    nach einen speziellen font aus, ist das der .ttf aus dem music-plugin? (und darf man den eigentlich
    dann in ein vdr-graphlcd release packen?


    und bitte immer den bugtracker nutzen, da bekomm ich automatisch emailnachricht wenns was neues.


    -- randy

  • Quote

    Original von Zoolook
    Wenn man nun VDR erstmal aussen vor lässt und mit graphlcd-base-0.1.9 folgendes probiert


    also bei mir geht das uebrigens nicht:


    # echo $LANG
    de_DE.UTF-8
    # showtext --config /etc/graphlcd.conf --encoding utf8 --display ks0108 --font ft2:/vdr/vdr-1.6.0/plugins/music/fonts/VDRSymbolsSans.ttf:22 ÖÄ


    kommen nur 2 kaestchen.


    uebrigens hast du immer noch git schreibrechte, als zooloc.


    -- randy

  • Zwei Fragen zu den UTF-8 Patches:


    - Ist das schon die Version ohne Segmentation-Faults?
    - Muss es sein, dass der Code zum Decodieren der UTF-8 Sequenzen dreimal im Code vorkommt?


    Ich halte dieses UTF-8-Thema für überbewertet. Im deutschen Sprachraum kommt man gut ohne UTF-8 aus. Interessant ist es aber natürlich für Benutzer, die Sprachen nutzen wollen, die ohne Unicode nicht können. Sofern es solche Benutzer in nennenswertem Umfang gibt...