[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.

Zitat

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

<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

Zitat

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".

Zitat

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...

Zitat

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

?

Zitat

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

Zitat

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

Zitat

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.

Zitat

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

<block condition="and(le({DateTime:%S},30),{ServiceIsAvailable:femon})">
					<!-- Info Pane -->
					<rectangle x1="174" x2="237" y1="2" y2="49" color="black" filled="yes"/>
					<progress x1="176" x2="235" y1="4" height="10" color="white" direction="0" current="{ServiceItem:femon,percent_signal}" total="100"/>
					<text x1="176" x2="235" y1="15" height="FontLineHeight('Fontfemon')" color="white" align="left" font="Fontfemon">
						STR:
					</text>
					<text x1="176" x2="235" y1="15" height="FontLineHeight('Fontfemon')" color="white" align="right" font="Fontfemon">
						{ServiceItem:femon,percent_signal}%
					</text>
					<progress x1="176" x2="235" y1="27" height="10" color="white" direction="0" current="{ServiceItem:femon,percent_snr}" total="100"/>
					<text x1="176" x2="235" y1="38" height="FontLineHeight('Fontfemon')" color="white" align="left" font="Fontfemon">
						SNR:
					</text>
					<text x1="176" x2="235" y1="38" height="FontLineHeight('Fontfemon')" color="white" align="right" font="Fontfemon">
						{ServiceItem:femon,percent_snr}%
					</text>
</block>

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.

Zitat

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.

Zitat

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..

Zitat

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.

Zitat

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.

Zitat

Originally posted by Morone
Aber wo liegt denn da der Sinn

Wie würdest du es machen?

Zitat

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

Zitat

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.

Zitat

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):

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:
[Blockierte Grafik: 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):
[Blockierte Grafik: 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

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

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

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.

in Zeile 796 ist auch noch mal ein month vorhanden. Muss das nicht auch noch konvertiert werden?

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

Zitat

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.

Zitat

Original von Zoolook
Doch, sogar schon etwa seit 0.1.5 oder 0.1.6 mindestens.

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?

Zitat

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...

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...