Posts by S:oren

    Ist das ein generelles Problem bei TVs oder samsung-spezifisch?

    Welche Tasten direkt verarbeitet und welche per CEC durchgereicht werden, ist eine Eigenschaft des Fernsehers. Vermutlich werden sich hier Produkt-Serien eines Herstellers wenig unterscheiden. Denkbar waere, dass sich sowas im Fernseher konfigurieren laesst, habe ich aber noch nicht gesehen.


    Wie habt Ihr das gelöst?

    Nur Tasten dem VDR zuordnen, die auch weitergeleitet werden. Manchmal unterstuetzt ein Fernseher verschiedene Fernbedienungs-Modelle, wo sich evt. auch zusaetzliche Tasten finden. Ansonsten bleibt nur, sonst ungenutzte Tasten mit eigentlich "falscher" Beschriftung im VDR zu verwenden.


    Gruss,

    S:oren

    Ein einfacher Blick in den Code ergibt: so ein Operator ist nicht definiert (hier ging es um die Klasse cFontManager),

    Auch keine andere Klasse in skinnopacity definiert einen operator delete oder delete[], falls es da noch Unklarheiten gibt...


    Gruss,

    S:oren

    Das hängt wohl davon ab, ob es da einen Operator Overload für das delete gibt (und wie der genau implementiert ist)

    Ein einfacher Blick in den Code ergibt: so ein Operator ist nicht definiert (hier ging es um die Klasse cFontManager), es gilt also die default-Implementierung, die perfekt mit nullptr beim delete() klar kommt...


    Gruss,

    S:oren

    Die letzten Commits sind jetzt in den Branch light_version gemerged.

    OK, danke.


    Dieses, und noch ein paar weitere sich anbietende Sachen, habe ich im Branch Devel-Light neu angelegt.

    Von C++ habe ich eigentlich nicht wirklich viel Ahnung, aber einige Sachen gefallen mir nicht so recht.


    Zunaechst meinte ich, den alten Commit zum Fontmanager anzupassen, und nicht zwei neue dazuzuerfinden. Das haette ich in einem Patch uebersichtlicher gefunden. Oder zumindest in aufeinanderfolgnden Patches. Aber OK, wenn es am Ende einfacher wird, bringt es etwas.


    Code
    1. + if (fontManager)
    2. + delete fontManager;

    Eher unguenstig. Das delete prueft selbst auf nullptr. Sowas ist auch an anderen Stellen noch drin.


    DELETENULL() finde ich generell sehr sinnvoll. Aber in einem Destruktor ist es nun wirklich vergebene Liebesmueh. Warum am Ende die Attribute noch schnell auf NULL setzen, wenn das ganze Objekt sowieso gerade zerstoert wird?

    Auch die andere Aenderung in dem ersten Fontmanager-Patch (in der alten Serie), die Null-Initialisierung im Header, ist unnoetig, wenn man sowieso im Konstruktor die ganzen Werte initialisiert. Das Nullen ist nun ueberfluessigerweise immer noch drin.

    Die ganze Idee, den fontManager zu loeschen und neu anzulegen, bringt ja nur etwas, weil man diese Zusatzinitialisierungen weglassen kann. Ansonsten ist es ja nur Overhead, wenn man den Speicher fuer das Objekt selber freigibt und gleich wieder alloziert.


    Weil wir gerade beim fontManager sind, hier sind nur die meisten Fonts drin, aber in displaymenuview.c, menudetailview.c und displaychannelview.c werden doch noch ein paar zusaetzlich lokal benutzt. Vermutlich noch ein Ziel fuer Aufraeumarbeiten. Solche Inkonsistenzen gibt es auch an anderen Stellen noch, so werden channellogos beim channelview aus dem imagecache genommen, aber beim Programm-Menue-Header nicht...


    Der letzte Patch zu cNopacityConfig ist auch wieder ein Vorbereitungspatch, um die ganzen Sachen dann direkt in Init zusammenzufassen?


    Ansonsten habe ich die neue Serie bei mir auch getestet, laeuft noch alles einwandfrei.


    Gruss,

    S:oren

    Ich habe mal die beiden commits neu aufgeteilt und hoffentlich besser beschrieben.

    Sehr schoen! Macht die ganze Sache viel uebersichtlicher.



    Aber erst mit dem letzten Commit funktioniert das mit den Grafiken im Menü richtig

    Bei mir immer noch der selbe Fehler. Aber jetzt ist der commit uebersichtlich genug, dass man etwas sieht.

    Ich denke, dass Problem ist, dass jetzt SetGeometry() vor config.LoadThemeSpecificConfigs(); config.SetThemeSpecificDefaults(); kommt, und dadurch nicht die richtigen Settings aktiv sind.


    Zusammenfassen von DeleteFonts() und SetFonts(), das habe ich mir aber noch nicht angesehen.

    Der ganze fontManager mit dem neuen Commit ist etwas unuebersichtlich. Statt SetFonts() und DeleteFonts() koennte man das doch in Konstruktor und Destruktor packen, und den ganzen fontMager erst anlegen, wenn die Settings klar sind, bzw. bei Aenderungen den ganzen fontManager loeschen und neu anlegen. Macht den Code bestimmt uebersichtlicher. Geht aber erstmal auch so.


    Gruss,

    S:oren

    Ich habe auch den Fehler mit der Geometrie gefunden, der war schon im commit "Eliminate cGeometryManager::SetOSDSize".

    Dieser Commit ergibt jetzt ueberhaupt keinen Sinn mehr. Statt des zweimaligen Aufrufs von SetOSDSize(); wird der Code zweimal hineinkopiert. Auch die Commit-Beschreibung passt nicht mehr.

    Hier gab es mit der Version vorher bei mir auch keinen Fehler (was aber an meinen Settings liegen kann).

    Der letzte ist aber OK so.

    Nein, immer noch der selbe Fehler.

    Es scheint mir, in diesem Commit werden mehrere verschiedene Sachen geaendert, die auch so nicht in der Beschreibung erklaert werden.

    Wenn Du den Commit aufteilst (die NULL-Geschichten, Fix der Debug-Logs, was da jetzt wieso anders initialisiert wird) und das jeweils erklaerst, dann kann man vielleicht auch nachvollziehen, was da schief geht.


    Gruss,

    S:oren

    Die genauen Zusammenhänge habe ich da auch noch nicht erkannt.

    Dann wuerde ich vorschlagen, diese beiden Commits wegzulassen. Irgendwas auszuprobieren, ohne zu verstehen was man tut, kann zu keinem stabilen Code fuehren.

    Und wenn die Themes jetzt kaputt sind, waere ein Revert der entspechenden alten Aenderung wohl am sinnvollsten...


    Gruss,

    S:oren

    Ich wuerde die beiden squashen.

    und fasse die beiden anderen Patches zusammen.

    War wohl gestern schon ein bisschen spaet. Anscheinend sind die Patches schon zusammengefasst, die sich mit CreateCacheDelayed(); befassen. Die beiden letzten sind schon komplett verschieden und sollten getrennt bleiben.


    Entschuldigung fuer den voreiligen Kommentar...

    S:oren

    6fc9c40bd686348b6761a3c97f6f61ac6a9d59be is the first bad commit

    fehlende Hintergrundgrafiken


    81e016a561f21e4e051a904729d7a46c27536589 is the first bad commit
    wieder mit Hintergrund, aber falsche Geometrie


    Ergibt das ueberhaupt einen Sinn, dieses in 2 Patches zu teilen? Ich wuerde die beiden squashen. Aber der Bug bleibt dann natuerlich trotzdem.

    Ich kann nochmal in den Code reinschauen, aber nicht mehr heute...


    Gruss,

    S:oren

    Used your test repository (github.com/pbiering/vdr-plugin-osdteletext), otherwise I would not see Version 1.0.6.2 as reported.


    OK, will ignore this and switch back to vdr-projects...


    Regards,

    S:oren

    Leider lassen sich einzelne Commits nicht uebersetzen. Sowas ist extrem schlecht und verhindert ein sinnvolles git-bisect...


    Gruss,

    S:oren

    Danke erstmal fuer Devel-Light.


    Leider sind die Menues damit alle kaputt, Darstellung einzelner Items außerhalb des sichtbaren Bereichs. Liegt vielleicht daran, dass ich Breite und Hoehe des OSD um ein paar Prozent verkleinert habe.


    Soll ich ein bisect starten?


    Gruss,

    S:oren

    Vorher wuerde ich gerne noch den letzten verbliebenen Bug fixen: die durch das nicht vdr-konforme Handling der Menueeintrage fehlende Möglichkeit, im remote-Plugin eine Fernbedienung anzulernen.

    Hab ich am Wochenende mal gefixt, siehe hier.


    Heute ist mir auch noch ein Bug mit Grafiken in beiden Versionen aufgefallen, den muss ich mal endgültig fixen.

    Was funktioniert da nicht richtig? Mir ist bisher nichts aufgefallen...


    Gruss,

    S:oren