nOpacity 0.0.4

  • Also ich persönlich finde ja skaliertes Video im OSD schon lästig genug. Aber wenn es auch noch dauernd in unterschiedlichen Größen und womöglich noch an unterschiedlichen Stellen erscheint, dann wird's langsam unerträglich.Aber das ist nur meine Meinung - es gibt ja anscheinend genügend Anwender, für die das OSD die eigentliche Anwendung ist und das Aufzeichnen und Wiedergeben von Sendungen nur ein netter Nebeneffekt... ;-).


    Der VDR ist einfach zu gut...die "Grundfunktionalitäten" werden einfach als gegeben vorausgesetzt. Gerade deshalb nochmal ein fettes "Danke", dass du dich mit den "bling bling" Themen beschäftigst, obwohl es dir eigentlich am A**** vorbeigeht :)


    Ciao Louis

  • Genau meine Meinug. Klar sind die "Grundfunktionen" das wichtigste, aber mit dem Aufkommen von HD wollen immer mehr halt auch optische Gimmiks. Und bevor alle "Optik-Freaks" an die "XBMC-Fraktion" verloren gehen finde ich es schon extrem wichtig, dass Möglichkeiten geschaffen werden, das VDR-Eigene OSD optisch ansprechender zu machen.

  • Genau meine Meinug. Klar sind die "Grundfunktionen" das wichtigste, aber mit dem Aufkommen von HD wollen immer mehr halt auch optische Gimmiks. Und bevor alle "Optik-Freaks" an die "XBMC-Fraktion" verloren gehen finde ich es schon extrem wichtig, dass Möglichkeiten geschaffen werden, das VDR-Eigene OSD optisch ansprechender zu machen.


    "Optisch ansprechender" ist ja recht und schön, aber man sollte sich dabei nicht zu sehr in Details "verlaufen" - und immer das KISS-Prinzip im Auge behalten ,-).


    Klaus

  • Moin!


    Ich bin auch dafür, allen vdr-eigenen Menüs eine eigene Id zu geben, damit man darauf reagieren kann.
    Ob es nun ein enum oder UUID ist, ist egal, da es für die UUID ja sicherlich Konstanten gibt, der Code sich also vom Lesen her nicht ändert.
    enum hat den Vorteil, dass es einfach nur ein Integer ist. Der lässt sich einfacher irgendwohin übergeben und vergleichen. Und 2^32 verschiedene Ids sollten wohl ausreichen... :)


    Lars.

  • Ob es nun ein enum oder UUID ist, ist egal, da es für die UUID ja sicherlich Konstanten gibt, der Code sich also vom Lesen her nicht ändert.


    Die Idee für UUIDs kam nur auf, da es hiermit möglich ist das Plugins Menüseiten benennen können ohne sich untereinander absprechen zu mussen. Das war halt für den Fall das Pulgins ihre Menüseiten auch benennen können, aber das wurde ja eh zu den Akten gelegt.


    Also für VDR-eigene Menüs kann man diese UUID Sache wohl ignorieren ;)


    cu

  • Fein Fein...dann harre ich mal der Dinge :)


    Was allerdings bedeutet, dass ich das Einbauen des schmalen Menüs für den "Settings" Bereich erst mal auf Eis lege und an anderen Ecken weitermache...sorry BooStar, deine Icons werden dann noch ein bisschen warten müssen, bis sie in Aktion treten können :)


    Ciao Louis

  • Fein Fein...dann harre ich mal der Dinge :)


    Was allerdings bedeutet, dass ich das Einbauen des schmalen Menüs für den "Settings" Bereich erst mal auf Eis lege und an anderen Ecken weitermache...sorry BooStar, deine Icons werden dann noch ein bisschen warten müssen, bis sie in Aktion treten können :)


    Ciao Louis


    Könnte man nicht bis zur Lösung temporär beim verlassen des Unteruntermenus das OSD ganz schließen? Bei meinen Tests habe ich festgestellt, dass der Absturz audbleibt, wenn man zum Verlassen Menu drückt und nicht Exit/Back... Nur so eine Idee... Sieht nämlich schon geil aus, schmal und mit den BooStar-Bildchen.


    Gruß, Ingo

  • Könnte man nicht bis zur Lösung temporär beim verlassen des Unteruntermenus das OSD ganz schließen? Bei meinen Tests habe ich festgestellt, dass der Absturz audbleibt, wenn man zum Verlassen Menu drückt und nicht Exit/Back... Nur so eine Idee... Sieht nämlich schon geil aus, schmal und mit den BooStar-Bildchen.


    Klar schaut es geil aus...ich hab es ja gestern auch sehen können...aber in dem Zustand mag ich das nicht mit reinnehmen. Ich "sehe" im Skin die Usereingaben nicht, der Skin reagiert nur. Also nix mit "OSD schließen" :) Und den Leuten sagen, benutzt nur "Menü" und nicht "Exit"...nenene :(


    Aber es gibt doch noch genügend andere fehlende Features...jetzt kann ichm ich z.B. den EPG Bilderchen und sonstigem in Ruhe widmen :)


    Ciao Louis

  • ...ne, das habe ich selbst nicht hinbekommen - immer wollte der Finger exit drücken. War nur so eine Idee - eine der unausgegorenen Art...


    Lucian: Deine neuen Patches laufen hier seit ca. 3h. Bisher ohne jegliche Probleme (bis auf das scale-vollbild-Problemchen, aber da hat kls Dich ja auf eine Iee gebracht). Das Bild liegt auch nicht mehr unter dem Scrollbar der Menus. Alles gut. Danke.


    Gruß, Ingo

  • Hallo zusammen..


    Zitat

    Was allerdings bedeutet, dass ich das Einbauen des schmalen Menüs für den "Settings" Bereich erst mal auf Eis lege und an anderen Ecken weitermache...sorry BooStar, deine Icons werden dann noch ein bisschen warten müssen, bis sie in Aktion treten können


    hehe .. aufjedenfall..die Ansicht für die Settings ist mir eigentlich egal ;) .. Ich habe die Logos zum Spass gemacht und weil ich dachte damit kann ich jedenfalls ein bischen helfen ;)
    Freuen würde ich irgendwann mal über eine alternative Ansicht der Timer, ich finde es ein bischen Schade das damit das Bild verdeckt wird. Das aber kann aufjedenfall ans Ende deiner Liste ;)


    [size=10]nOpacity: Icons
    [size=10]skindesigner: tryoutsglassy

  • Freuen würde ich irgendwann mal über eine alternative Ansicht der Timer, ich finde es ein bischen Schade das damit das Bild verdeckt wird. Das aber kann aufjedenfall ans Ende deiner Liste ;)


    Willst du die Timer ganz ausblenden können oder willst du sie irgendwo anders im Hauptmenü in anderer Darstellung haben?


    Ciao Louis

  • Hi louis,
    das eine schliesst das andere ja nicht aus ;)
    ich finde es machmal ganz praktisch, wenn ich schnell sehen kann welche Timer grade laufen, aber ich weiss auch grade nicht wo man sie am besten positioniert.
    Da wo sie jetzt finde finde ich es aufjedenfall nicht gut ;) Da blende ich sie lieber aus..


    [size=10]nOpacity: Icons
    [size=10]skindesigner: tryoutsglassy

  • Na das ist doch ein Angebot :) Machen wir es anders herum, die Zeilen 229 und 230 (displayMenu->SetTitle(title); cStatus::MsgOsdTitle(title);) sollten zwei Zeilen nach oben, also am besten direkt hinter "displayMenu->SetMenuCategory(menuCategory);" das sollte eigentlich keine unerwünschten Seiteneffekte haben?


    Wenn ich es mir recht überlege, dann muß SetMenuCategory() doch sehr früh aufgerufen werden, um abgeleiteten Klassen die Möglichkeit zu geben, diese Information so früh wie möglich zu erhalten. Denn davon können ja wiederum so DInge wie MaxItems() abhängen.
    Ich werde auf jeden Fall eMenuCategory entsprechend erweitern.
    Meinetwegen können wir da auch noch jede Menge "abstrakte" Kategorien mit aufnehmen, die zwar VDR selber nicht braucht, die aber von Plugins verwendet werden könnten. Spontan fallen mir da ein mcGame, mcWeather, mcMail, mcNews... Wichtig dabei ist, daß eine Skin nicht ein ganz bestimmtes Plugin "kennen" soll. Eine Skin mit einem konkreten Plugin zu "verheiraten" ist einfach falsch. Und da eventuelle Icons ja zur Skin passen müssen, kann ein Plugin schlecht ein Icon vorgeben. Letztendlich würde das darauf hinauslaufen, daß entweder in einer Skin alle möglichen, unterschiedlich gestalteten Icons erscheinen, oder daß jedes Plugin sein Icon für alle möglichen Skins vorhalten müsste. Beides erscheint mir nicht gut.
    Falls also weitere abstrakte Kategorien gewünscht sind, bitte hier posten.


    Klaus

  • Hi,


    mittlerweile hat sich Johns bei mir mit seiner Variante (Anhang 0001-softhddevice-output_pos-johns.diff) des eigentlichen Skalierungs-Codes (welches theoretisch auch mit dem alten YaEPG-Hack nutzbar wäre) gemeldet. Darauf aufbauend, und auch nach den Vorschlägen von Kls habe ich nun die Kapselung der Skalierung in der neuen vdr-1.7.33 API nochmals überarbeitet. Ich musste Johns Patch aber noch ein bisschen anpassen (Anhang 0002-softhddevice-output_pos-johns+lucian.diff) und danach kommt Nummer 0003 mit der eigentlichen API-Änderung, und wie gehabt, auch der nOpacity-Patch. Bei mir funktioniert nun diese Variante, (logischerweise in der Reihenfolge der Nummerrierung eingespielt) mittlerweile einwandfrei:


    • Kein Flackern mehr, dank Kls' Tipp;
    • Skalierung und Positionierung auch bei SD 4:3, mit oder ohne letterbox, sowie SD 16:9 und HD was sowieso immer 16:9 markiert ist ist nun korrekt, auch wenn man bei softhddevice zwischen "Normal" und "Stretched" (nun gut, bei Stretched bleibt naturgemäß das Seitenverhältnis nicht mehr akkurat, das könnte man noch nachreichen mit "Anamorphic", was softhddevice momentan noch fehlt).


    Einen nicht so schönen, aber weg-diskutierbaren Effekt gibt es noch, wer damit sich tatsächlich Yaepghd antun will (Patches hier , funktionieren mit dem YaEPG-eigenen anthra_1920 Theme auch wenn man nOpacity nutzt), wird sehen dass zwischen Umschalten vom VDR-Menü welches mit nOpacity ja schon skaliert ist und dem YaEPG-Menü welches seinen OSD selber zu zeichnen scheint, im eigenen Theme, wird zwischenzeitlich hochskaliert, weil meiner Ansicht nach immer im Destruktor des OSD-Objektes hochskaliert werden muss, sonst kommt das Ganze aus dem Tritt. Muß man sich aber nicht wirklich antun, kann man aber als Demonstration der Skalierung ausprobieren...


    Ciao, Lucian


    Edit 03.01.2013: Die notwendigen Patches wurden mittlerweile immer weniger :]...

  • Wenn ich es mir recht überlege, dann muß SetMenuCategory() doch sehr früh aufgerufen werden, um abgeleiteten Klassen die Möglichkeit zu geben, diese Information so früh wie möglich zu erhalten. Denn davon können ja wiederum so DInge wie MaxItems() abhängen.
    Ich werde auf jeden Fall eMenuCategory entsprechend erweitern.


    Aber es sollte doch so passen, wie es aktuell ist? SetMenuCategory() wird direkt nach Clear aufgerufen, also vor allem anderen und insbesondere vor MaxItems...für mich ist einfach wichtig, dass ich immer und an jeder Stelle genau weiss, in welchem Menü ich mich befinde, dann kann ich mir die "Handstände" komplett sparen :)


    Ich freu mich schon auf VDR 1.7.34 :)


    Ciao Louis

  • louis
    ich habe noch drei Kleinigkeiten:
    Bei arghdirector scrollen die Titel hier nur in einem Bereich der dem linken Hauptmenü mit der Einstellung auf 20% entspricht - sprich die Titel werden zu kurz abgeschnitten... Kann das jemand verifizieren?


    Und wäre es Möglich ähnlich dem Anthra-Skin Kategorien-Symbole zuzulassen? Also beispielsweise HD+, Sport usw. die dann beim rechtslinks-scrollen durch die Kanalgruppen statt des Separators erscheinen?


    Außerdem wäre cool, wenn bei der EPG-Ansicht NUR der Titel gescrollt würde, nicht ins Logo laufen würde und auch zurückscrollen würde...


    Ansonsten alles TRAUMHAFT :D

  • Eben! Und deswegen werde ich das auch nicht ändern ;)
    Wollte es halt nur der Vollständigkeit halber gesagt haben...


    Die vorgeschlagene Änderung war auf SetTitle() bezogen, das ist aber jetzt mit der Einführung der neuen Untermenükategorien hinfällig...also alles gut :)


    Ciao Louis

  • Lucian: das klingt super, das muss ich mal ausprobieren. Seit gestern hab ich nun auch VDR 1.7.33 am laufen :)


    Ist der Patch aus deiner Sicht reif, um ins Git zu wandern?


    Ich bin mir noch nicht so ganz sicher, wie ich bezüglich Voraussetzungen weitermachen soll...soll ich für die Entwicklung, die VDR 1.7.33 voraussetzt einen neuen Branch erstellen und Änderungen, die auch mit der aktuellen Voraussetzung 1.7.30 funktionieren in master Branch weiterführen und dann in den neuen Branch mergen? Oder soll ich nur mit dem master branch weitermachen und direkt VDR 1.7.33 voraussetzen? Wäre dann viele von euch ausgeschlossen oder wäre das kein Problem? Direkt VDR 1.7.33 als Voraussetzung wäre natürlich vom Handling her einfacher...


    Ciao Louis

  • Hi,


    Bei arghdirector scrollen die Titel hier nur in einem Bereich der dem linken Hauptmenü mit der Einstellung auf 20% entspricht - sprich die Titel werden zu kurz abgeschnitten... Kann das jemand verifizieren?


    Ich kenne arghdirector nicht...arbeitet das Plugin mit den "normalen" OSD Elementen? Braucht man dazu Sky, um das sinnvoll testen zu können? Vielleicht kannst du das mal ein bisschen genauer erklären und einen Screenshot einstellen...


    Und wäre es Möglich ähnlich dem Anthra-Skin Kategorien-Symbole zuzulassen? Also beispielsweise HD+, Sport usw. die dann beim rechtslinks-scrollen durch die Kanalgruppen statt des Separators erscheinen?


    Prinzipiell kein Problem...die Kurx aus meiner Sicht ist, dass jeder unterschiedliche Kanalgruppen definiert hat und wir da zig verschiedene Icons benötigen. Das war der Grund, warum ich mich für ein universelles Ordnersymbol entschieden habe. Wenn du eine gute Idee hast, wie man das allgemein lösen kann, dann als her damit, eingebaut ist das schnell.


    Außerdem wäre cool, wenn bei der EPG-Ansicht NUR der Titel gescrollt würde, nicht ins Logo laufen würde und auch zurückscrollen würde...


    Ich finde es so schick, insbesondere, dass der Text auch hinter das Logo scrollt...ich habe mir auch überlegt, den Titel und den Subtitel einzeln scrollen zu lassen, jedoch benötige ich pro scrollendem Text eine Pixmap, und die Anzahl der Pixmaps ist auf insgesamt 64 beschränkt...irgendwann würde man da ans Limit kommen, deshalb habe ich mich dagegen entschieden.

    Ciao Louis

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!