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

gefixt (bloed, wenn die konstante (logischerweise) befuellt wird BEVOR das vdr-eigene i18n-zeug initialisiert ist - compile- vs. runtime ...).

alles andere neben der description sollte aber keine probleme machen?

neuigkeiten:

• support fuer alpha channel

einschraenkung: bei texten mit einem font-effect (outline, shadow) funktionierts leider nicht brauchbar (aufgrund der art und weise, wie die effekte derzeit erzeugt werden).

neuigkeiten:

• alpha channel: texte mit font-effekten werden jetzt auch brauchbar unterstuetzt
• opacity support fuer images -> zusaetzlicher parameter fuer <image />: opacity="<value>", <value> = [0, 255], default 255

bug fix:

• bug(s) in WrapText() versucht zu beheben (-> mesg <langertext>)

um test wird gebeten

EDIT: damnit, in manchen situationen wird dzt. immer noch ein teil eines buchstaben abgeschnitten ...
utf8-tauglich ist das ganze auch nicht. da werde ich wohl diese methode mal neu schreiben muessen ...

EDIT2 (2011-06-23):
jetzt aber sollten die div. probleme v. WrapText() behoben sein:

• UTF8 sollte keine probleme mehr bereiten
• buchstaben werden korrekt umgebrochen (kein buchstabe sollte mehr zerschnitten sein)
• weitere trennzeichen, an denen bevorzugt umgebrochen werden kann, hinzugefuegt: "-.,:;!?_"

neuigkeiten:

• alle treiber sollten jetzt mit der 32bit colour internen darstellung zusammenarbeiten (jeder treiber hat jetzt eine gueltigte SetPixel()-Methode). ABER: alle bis auf simlcd und serdisp sind ungeprueft!!
• Set8Pixels() ist nicht laenger 'virtual', sondern ab jetzt eine in der basis-klasse definierte generische methode.

ACHTUNG: wegen der aenderung bei Set8Pixels() muss auch vdr-plugin-graphlcd neu kompiliert werden (ansonsten segfault!).

-> dieser branch schreitet langsam aber sicher einem release candidate entgegen ...

Keine_Ahnung:
sehe ich mir an. habe zwar auch sender ohne logo (und da kein problem), aber mal schauen, was das wieder fuer ein spezialfall ist ...

EDIT: damnit, wohl derselbe fehler wie im anderen constructor:
ersetz mal in zeile 100 (bitmap.c):

bitmap = new uint32_t[width * height];
Clear(initcol);

durch

if (width > 0 && height > 0) {
bitmap = new uint32_t[width * height];
Clear(initcol);
}

neu:

• bei 1bpp imagemagick bildern wird jetzt das monochrome flag gesetzt (und schwarz und weiss entsprechend aufbereitet) => 'color' und 'bgcolor' werden jetzt beruecksichtigt.

der bugfix fuer cBitmap constructor wird spaeter committed (ist gerade groessere baustelle (anpassen der div. Save*-methods() an die 32bpp internas)

try/catch: du kannst es ja ausprobieren (ich kanns nicht testen in ermangelung fuer radio-plugin verwertbarer sender (dvb-t)).
einfach in service.c:
ab zeile 269 (nach zeile radioActive = true; )
das ganze if() {} (zeile 269-286) umschliessen mit:

try{
< if() {} zeug >
} catch (...) {
isyslog("graphlcd plugin: strcmp() crashed when receiving broken crap from radio plugin \n");
}

die drei '...' beim catch sind tatsaechlich ernst gemeint ( die drei punkte bedeuten: jede moegliche exception )

EDIT:
vergiss das mit try/catch:
das kann einen runtime error in strcmp() nicht abfangen wie es scheint (getestet mit einem kleinen beispielprog.):

#include <stdio.h>
#include <cstring>


int main (int argc, char** argv) {
  char* bla1 = NULL;
  try {
	int rv = std::strcmp(bla1, "bla");
	printf("strcmp ok\n");
  } catch(...) {
	printf("exception caught\n");
  }
  return 0;
}

-> segfaultet genauso (egal ob strcmp (v. string.h) oder std::strcmp)

es ist auch in der definition v. strcmp() so festgeschrieben, dass das ergebnis undefiniert ist, wenn ein parameter null ist.

neuigkeiten:

• graphlcd-base: habe das setzen v. monochrome-flag fuer imagemagick bilder einstweilen wieder deaktiviert (das ist dann doch aufwaendiger als gedacht)
• vdr-plugin-graphlcd: paranoia mode fuer strcmp. wenn das auch nicht hilft dann muss das wohl jmd. mit rds-faehigen radiosendern debuggen (gdb, mit dem man dann auch die konkreten inhalte der structs sehen kann).

neu:

• crtfont und genfont sollten jetzt wieder funktionieren (div. tests waren erfolgreich, die generierten fonts (.fnt) haben funktioniert)
• cPBMFile kann jetzt korrekt speichern (Save())
• aus cBitmap wurden LoadPBM()/SavePBM() entfernt (die wurden ohnedies nur von crtfont und genfont verwendet). fuer das laden und speichern von PBMs ist jetzt ausschliesslich die klasse cPBMFile verantwortlich (auch crtfont und genfont verwenden jetzt diese klasse).

hoffe, dass ich keine nebeneffekte hineingebracht habe, waren doch einige grundlegende aenderungen. meine tests brachten aber keine auffaelligkeiten zu tage ...

neu

• treiber fuer futabaMDM166A hinzugefuegt (aus 0.1.x) und angepasst
• mem leak fix fuer image.c (aus 0.1.x) portiert
• aktuellen noritake800 aus 0.1.x genommen und angepasst

recht viel fehlt glaube ich nicht mehr dass alle funktionalitaeten v. 0.1.x jetzt auch im touchcol-branch unterstuetzt werden?

so ein problem sehe ich da nicht. hatte dazu auch schon mal eine idee dazu, das ganze relativ skalier-/anpassbar/flexibel zu machen. bloederweise habe ich damals das music-plugin (oder das plugin, das man dafuer benoetigt - weiss den namen nicht mehr) nie zum laufen gebracht. habe es aber auch schon lange nicht mehr versucht.

spiele bereits mit span herum, die abfrage der daten ist bereits fertig implementiert, gezeichnet wird das ganze mit existierenden gfx-objekten (im screenshot: balken: <progress/>-bars, rahmen: <rectangle/>, labels (L/R): <text/>)
das object <progress/> moechte ich noch um die zusatzfunktion 'peak' erweitern, dann wird auch die anzeige der peaks moeglich sein.

das ganze ist, da kein eigenes span-anzeigeobjekt notwendig ist, sehr flexibel (im screenshot: volume anzeige: horizontal, spec. analyser: vertikal, die daten kommen von einer gemeinsamen quelle (gibt ja auch nur eine )

produktiv verwendbar ist es derzeit noch nicht (habe noch segfaults).