Setup-Menü mit dynamischer Breite

FireFly · May 18, 2026 at 4:35 PM

Quote from kls

Kann es evtl. damit zu tun haben, dass durch deine Änderung das Plugin überhaupt neu übersetzt wurde?

Ja, das wirds gewesen sein, Danke. Habe Setup() wieder in Set() geändert und es geht immer noch. Auch das mit fehlenden Tabs geht mit der #06.

Was mir aber noch aufgefallen ist (mit Debugausgabe der Pixelbreite pro Item): Wenn man Cursor hoch/runter tippt wird die Pixelbreite korrekterweise nicht neu berechnet, aber bei rechts/links um seitenweise zu Springen wird die Pixelbreite jedesmal komplett neu berechnet.

kls · May 18, 2026 at 4:39 PM

Quote from FireFly

aber bei rechts/links um seitenweise zu Springen wird die Pixelbreite jedesmal komplett neu berechnet.

Das liegt daran, dass dann ein kompletter Display() gemacht wird. Bei Up/Down wird nur die alte und die neue Zeile dargestellt.

~~Ich versuche mal, den Wert zu cachen...~~

<edit>
Keine gute Idee, denn falls sich der Inhalt des Menüs dynamisch verändern sollte, könnte das Probleme machen. Ausserdem hat ein Setup-Menü in der Regel nicht sooo viele Einträge.
</edit>

kls · May 18, 2026 at 4:48 PM

Quote from kamel5

Ja, ich übersetzte immer alles neu.

Dann weiß ich im Moment auch nicht weiter.

kamel5 · May 18, 2026 at 5:12 PM

Quote from kls

Wenn das SubMenu auch wieder ein cMenuSetupPage ist

Ich sehe gerade, die SubMenus werden von cOsdMenu abgeleitet, und das HauptSetupMenu von cMenuSetupPage.
Das HauptSetupMenu funktioniert, die SubMenus nicht.
Ich weiß jetzt nicht, ob das die Ursache dafür ist. Der Code ist historisch nicht von mir, so das ich erst einmal schauen müsste, wie ich das umbauen kann. Das könnte aber etwas dauern.

FireFly · May 18, 2026 at 7:04 PM

Quote from kls

Keine gute Idee, denn falls sich der Inhalt des Menüs dynamisch verändern sollte, könnte das Probleme machen

Dann ist #06 aus meiner Sicht ok

<Edit>
Jetzt stellt sich natürlich die Frage, ob es generell sinnvoll wäre negative Tabs (1-5) als Pixelanzahl zu interpretieren ....
Die Skins bekommen ja sowieso immer die Anzahl Pixel geliefert, aber hätte das ein Vorteil für Plugins wenn sie Tabs pixelgenau setzen könnten?
</Edit>

kls · May 18, 2026 at 9:36 PM

Quote from FireFly

Jetzt stellt sich natürlich die Frage, ob es generell sinnvoll wäre negative Tabs (1-5) als Pixelanzahl zu interpretieren ....

Spricht meines Erachtens nichts dagegen.
Hier mal eine Code-Version, die das erlauben würde:

Code

void cSkinDisplayMenu::SetTabs(int Tab1, int Tab2, int Tab3, int Tab4, int Tab5)
{
#if 0
  if (Tab1 < 0 && Tab2 == 0) {
     memset(tabs, 0, sizeof(tabs));
     tabs[1] = -Tab1;
     return;
     }
  tabs[0] = 0;
  tabs[1] = Tab1 ? tabs[0] + Tab1 : 0;
  tabs[2] = Tab2 ? tabs[1] + Tab2 : 0;
  tabs[3] = Tab3 ? tabs[2] + Tab3 : 0;
  tabs[4] = Tab4 ? tabs[3] + Tab4 : 0;
  tabs[5] = Tab5 ? tabs[4] + Tab5 : 0;
  for (int i = 1; i < MaxTabs; i++)
      tabs[i] *= AvgCharWidth();
#else
  tabs[0] = 0;
  tabs[1] = Tab1;
  tabs[2] = Tab2;
  tabs[3] = Tab3;
  tabs[4] = Tab4;
  tabs[5] = Tab5;
  for (int i = 1; i < MaxTabs; i++) {
      tabs[i] *= (tabs[i] < 0) ? -1 : AvgCharWidth();
      tabs[i] += tabs[i - 1];
      }
#endif
}

Display More

Es sind beide Varianten drin zum Ausprobieren. Damit wären sogar gemischte Angaben möglich, also manche Spalten in Pixel, andere in Character. Ich habe jetzt nur das Setup-Menü getestet (also Tab1 < 0, Tab2 = 0) und das funktioniert noch (sowohl Text als auch Grafik Skins. Vielleicht mag ja jemand damit experimentieren und sagen, ob das sinnvoll wäre.

kls · May 18, 2026 at 10:48 PM

Ich habe jetzt noch einen Check eingebaut für den Fall, dass es gar kein Item mit Tab gibt.

Der Code aus #46 ist auch enthalten. Die Beschreibung von SetCols() und SetTabs() werde ich noch entsprechend anpassen, sollte sich diese Version von SetTabs() als sinnvoll und funktionsfähig erweisen.

Falls keine Fehler mehr auftauchen würde ich den Code in "#if 0" löschen und das Ganze so übernehmen.

cocobrother · May 18, 2026 at 11:10 PM

Wenn man sich den aktuellen Patch-Verlauf anschaut, wird deutlich, wie viele unerwartete Seiteneffekte eine automatische Berechnung im bestehenden OSD-System hervorruft.

Der Ansatz, die ermittelte Pixelbreite künstlich über ein negatives Vorzeichen als Flag durch die bestehende API zu schleusen, funktioniert zwar im ersten Moment, führt aber zu einer recht komplexen "Magic-Value"-Logik in der Layout-Berechnung. Das Ermöglichen von gemischten Angaben – manche Spalten in Pixeln, andere in Zeichenbreiten – macht die Wartung und das spätere Debugging bei Fehlern in Plugins extrem unübersichtlich.

Gleichzeitig wird genau hier die Ursache für das von kamel5 beschriebene Problem bei den Untermenüs deutlich: Durch das sofortige Abbrechen der Berechnung, sobald ein Submenü existiert, wird die Logik für das aktuelle Menü komplett übersprungen. Wenn ein Plugin nun seine Submenüs historisch bedingt von cOsdMenu ableitet und nicht von cMenuSetupPage, greift die neue, überschriebene Display-Logik dort überhaupt nicht. Das Submenü fällt auf die alte Basisklasse zurück, berechnet nichts Neues, und die zweite Spalte verschwindet im Nirvana. Das zeigt einfach, wie unterschiedlich die Ebenen in der gewachsenen Klassen-Hierarchie reagieren.

Man sieht an der Dynamik der letzten Stunden sehr gut, wie schwer es ist, alle Sonderfälle einer jahrelang gereiften Plugin-Landschaft per Core-Automatismus abzufangen. Vielleicht wäre der von SHofmann eingebrachte Vorschlag – ein statischer, im Setup einstellbarer Pixel- oder Zeichenwert für die erste Spalte – am Ende doch der stabilere, transparenteste und für alle Plugins sicherste Weg. Es würde den Core pragmatisch entlasten und solche kniffligen Sonderfälle von vornherein verhindern.

SHF · May 18, 2026 at 11:50 PM

Quote from kls

Das tut er immer schon:
skins.h: static int AvgCharWidth(void) { return Setup.FontOsdSize * 4 / 6; }

Aber FontOsdSize ist doch die Höhe (oder Größe).
4 / 6 ist ein fester Faktor, mit der Annahme, dass das Breite/Höhe-Verhältnis ca. 2/3 Beträgt.
AvgCharWidth ist also von der Höhe anhängig, nicht der Breite.

Wenn man, wie ich, einen Font mit schmalerer Laufweite (bei gleicher Höhe) verwenden will, haut das natürlich nicht hin.
Das Ergebnis ist dann wie beobachtet:
Die Spalten bleiben genau so groß wie vorher, sind aber hinten leer.

Evtl. sollte man als erstes mal diesen Wert wirklich bestimmen.
Das wäre nur eine Stelle, die geändert werden muss und wenn man Glück hat löst das Spaltenproblem gleich mit.
Zumindest hätte man dann einen zuverlässigen Mittel-Wert, wie Breit der verwendete Font wirklich läuft.
Wenn hier mit unterschiedlich breiten Fonts getestet wird, passt das sonst doch immer beim einen und beim anderen nicht.

cocobrother · May 19, 2026 at 7:11 AM

SHF trifft hier absolut den Nagel auf den Kopf. Das ist genau die logische Sollbruchstelle, an der das aktuelle System scheitert.

Wenn der Core die durchschnittliche Zeichenbreite (AvgCharWidth) starr über die Schrifthöhe schätzt, statt sie tatsächlich zu messen, kann die automatische Spaltenberechnung bei proportionalen Schriften hinten und vorne nicht hinkommen. Sobald jemand einen Font mit schmalerer oder breiterer Laufweite nutzt, läuft die 2/3-Schätzung ins Leere. Das erklärt perfekt, warum die Patches bisher bei dem einen funktionieren und beim nächsten das Layout zerschießen.

Den Wert an dieser zentralen Stelle einmal wirklich dynamisch vom geladenen Font bestimmen zu lassen (anstatt ihn blind zu schätzen), wäre der einzig saubere Weg, um das aktuelle Problem an der Wurzel zu packen.

Aber eigentlich zeigt uns diese ganze Diskussion doch noch etwas viel Fundamentaleres: Wir versuchen hier gerade mit enormem Aufwand, ein 25 Jahre altes Text-Raster-Konzept mit Patches ins moderne TrueType-Zeitalter zu prügeln. Vielleicht ist genau das jetzt der perfekte Wendepunkt, um mal laut darüber nachzudenken, das Menü- und OSD-System im Core auf völlig neue, zeitgemäße Füße zu stellen, anstatt immer komplexere Pflaster auf das alte Fundament zu kleben.

kls · May 19, 2026 at 9:59 AM

Quote from kamel5

Ich sehe gerade, die SubMenus werden von cOsdMenu abgeleitet, und das HauptSetupMenu von cMenuSetupPage.
Das HauptSetupMenu funktioniert, die SubMenus nicht.

Kann es sein, dass deine von cOsdMenu abgeleiteten SubMenus nicht SetCols() aufrufen (bzw. einen Wert im Constructor angeben)? Warum das bisher funktioniert hat, weiß ich dann zwar auch nicht, aber das könnte eine mögliche Erklärung sein.

kls · May 19, 2026 at 10:43 AM

Quote from SHF

Wenn man, wie ich, einen Font mit schmalerer Laufweite (bei gleicher Höhe) verwenden will, haut das natürlich nicht hin.

Wie sieht denn jetzt das Setup-Menü bei dir mit dem Patch aus #47 aus?

FireFly · May 19, 2026 at 11:47 AM

Quote from kls

Vielleicht mag ja jemand damit experimentieren und sagen, ob das sinnvoll wäre.

Ich habe den Patch #07 mit dem systeminfo Plugin ausprobiert und es funktioniert einwandfrei mit dem neuen Code, sowohl wie bisher mit Chars als auch mit Pixel.

Edit: Da drei Spalten benutzt werden, werden die Pixel für Tab1 und Tab2 berechnet

kamel5 · May 19, 2026 at 1:12 PM

Quote from kls

Kann es sein, dass deine von cOsdMenu abgeleiteten SubMenus nicht SetCols() aufrufen (bzw. einen Wert im Constructor angeben)? Warum das bisher funktioniert hat, weiß ich dann zwar auch nicht, aber das könnte eine mögliche Erklärung sein.

Die Aussagen beziehen sich auf den Patch aus #47.

Ich habe in die betroffenen Plugins mal ein paar Debugmeldungen eingebaut.
1. Es scheint so zu sein, das manchmal bei von cOsdMenu abgeleiteten SubMenus der Wert vom Constructor nicht benutzt wird, sondern nur ein explizites Angeben von SetCols() funktioniert. In diesem Fall gibt es eine Klasse "cMenuSetupSubMenu() : cOsdMenu(Title, 40) " (das funktioniert nicht) von der dann die eigentlichen Submenus abgeleitet werden.

2. ich habe einen Skin skinnopacity der nicht funktioniert. Dabei zeigt sich folgendes Verhalten.
Ohne den Patch werden folgende Werte von Tab zurückgeliefert:
Mai 19 12:14:15 home-05 vdr[225561]: [225561] skinnopacity: displaymenu.c SplitItem 562 Standard-Schriftart:
Mai 19 12:14:15 home-05 vdr[225561]: [225561] skinnopacity: displaymenu.c SplitItem 564 Tab(0)=1
Mai 19 12:14:15 home-05 vdr[225561]: [225561] skinnopacity: displaymenu.c SplitItem 567 tabItems(0)=1
Mai 19 12:14:15 home-05 vdr[225561]: [225561] skinnopacity: displaymenu.c SplitItem 574
Mai 19 12:14:15 home-05 vdr[225561]: [225561] skinnopacity: displaymenu.c SplitItem 562 VDRSymbols Sans:Book
Mai 19 12:14:15 home-05 vdr[225561]: [225561] skinnopacity: displaymenu.c SplitItem 564 Tab(1)=851
Mai 19 12:14:15 home-05 vdr[225561]: [225561] skinnopacity: displaymenu.c SplitItem 567 tabItems(1)=851
Mai 19 12:14:15 home-05 vdr[225561]: [225561] skinnopacity: displaymenu.c SplitItem 574
Mai 19 12:14:15 home-05 vdr[225561]: [225561] skinnopacity: displaymenu.c SplitItem 578 x=851
Mai 19 12:14:15 home-05 vdr[225561]: [225561] skinnopacity: displaymenu.c SplitItem 581
Mai 19 12:14:15 home-05 vdr[225561]: [225561] skinnopacity: displaymenu.c SetItem 516
Mai 19 12:14:15 home-05 vdr[225561]: [225561] skinnopacity: menuitem.c cNopacityDefaultMenuItem 1391
Mai 19 12:14:15 home-05 vdr[225561]: [225561] skinnopacity: menuitem.c Render 1570 posX=11 colWidth=846 Standard-Schriftart:
Mai 19 12:14:15 home-05 vdr[225561]: [225561] skinnopacity: menuitem.c Render 1570 posX=851 colWidth=939 VDRSymbols Sans:Book
Man sieht in den letzten beiden Zeilen posx jeweils für die erste und zweite Spalte.

Mit dem Patch ergibt sich folgendes Bild:
Mai 19 12:55:15 home-05 vdr[318626]: [318626] skinnopacity: displaymenu.c SplitItem 562 Standard-Schriftart:
Mai 19 12:55:15 home-05 vdr[318626]: [318626] skinnopacity: displaymenu.c SplitItem 564 Tab(0)=1
Mai 19 12:55:15 home-05 vdr[318626]: [318626] skinnopacity: displaymenu.c SplitItem 568 tabItems(0)=1
Mai 19 12:55:15 home-05 vdr[318626]: [318626] skinnopacity: displaymenu.c SplitItem 575
Mai 19 12:55:15 home-05 vdr[318626]: [318626] skinnopacity: displaymenu.c SplitItem 562 VDRSymbols Sans:Book
Mai 19 12:55:15 home-05 vdr[318626]: [318626] skinnopacity: displaymenu.c SplitItem 564 Tab(1)=-17342
Mai 19 12:55:15 home-05 vdr[318626]: [318626] skinnopacity: displaymenu.c SplitItem 568 tabItems(1)=-17342
Mai 19 12:55:15 home-05 vdr[318626]: [318626] skinnopacity: displaymenu.c SplitItem 575
Mai 19 12:55:15 home-05 vdr[318626]: [318626] skinnopacity: displaymenu.c SplitItem 581 x=-17342
Mai 19 12:55:15 home-05 vdr[318626]: [318626] skinnopacity: displaymenu.c SplitItem 584
Mai 19 12:55:15 home-05 vdr[318626]: [318626] skinnopacity: displaymenu.c SetItem 516
Mai 19 12:55:15 home-05 vdr[318626]: [318626] skinnopacity: menuitem.c cNopacityDefaultMenuItem 1391
Mai 19 12:55:15 home-05 vdr[318626]: [318626] skinnopacity: menuitem.c Render 1570 posX=11 colWidth=-17347 Standard-Schriftart:
Man sieht hier den großen negativen Wert, der von Tab(1) zurückgegeben wird. Dadurch wird nichts angezeigt und die zweite Spalte verschluckt.
Dieses Verhalten betrifft jeweils das von cMenuSetupPage abgeleitete Hauptsetupmenü von Plugins.
Die Frage ist halt jetzt, warum wird ein großer negativer Wert zurückgeliefert. Im Skin selber habe ich ja eigentlich keinen Einfluss darauf wie das Ergebnis von Tab() erzeugt wird.

kls · May 19, 2026 at 1:37 PM

Wo kann ich denn dieses Plugin downloaden, damit ich mir das mal selber anschauen kann?

kamel5 · May 19, 2026 at 1:49 PM

Quote from kls

Wo kann ich denn dieses Plugin downloaden, damit ich mir das mal selber anschauen kann

Hier: https://gitlab.com/kamel5/SkinNopacity

Die Funktion mit dem Tab() ist "cNopacityDisplayMenu::SplitItem()" in displaymenu.c.

Ja, die ist ein wenig wild, und ich weiß auch nicht, ob das alles nötig ist. Es gab bisher aber keinen Grund das zu ändern.

kamel5 · May 19, 2026 at 3:17 PM

Quote from kls

Kann man machen, ist aber nicht besonders elegant, weil die Texte zweimal vorkommen.
Wieso nicht so wie in cMenuSetup::Set()?

Es gibt 13 Menüpunkte, die so behandelt werden müssten. Es fehlt mir also osUser12 und osUser13. Könntest Du bitte die beiden noch zu "enum eOSState" in osdbase.h hinzufügen. Dann würde ich das so umbauen.

kls · May 19, 2026 at 3:48 PM

kamel5 Gibt es eine Möglicjkeit, das Plugin ohne das ganze GraphicsMagick-Zeug zu übersetzen? Der Raspberry Pi, auf dem ich entwickle, ist schon etwas älter, da kann ich das Paket leider nicht (mehr) installieren. Ich sollte mal auf ein neueres OS wechseln, aber nicht jetzt im Moment.

kls · May 19, 2026 at 3:52 PM

Quote from kamel5

Es gibt 13 Menüpunkte, die so behandelt werden müssten. Es fehlt mir also osUser12 und osUser13. Könntest Du bitte die beiden noch zu "enum eOSState" in osdbase.h hinzufügen. Dann würde ich das so umbauen.

Kann ich gerne machen. Ich füge dann osUser11...osUser20 hinzu. Benutze bitte nur die Konstanten ab osUser1, nicht os_User (letzterer hätte zwar keine negativen Auswirkungen, ist aber nicht dafür gedacht).

kamel5 · May 19, 2026 at 4:04 PM

Quote from kls

Gibt es eine Möglicjkeit, das Plugin ohne das ganze GraphicsMagick-Zeug zu übersetzen?

Nein, leider nicht. Der ursprüngliche Entwickler hatte den Skin als "eierlegende wollmilchsau" geplant und da ist das notwendig für die ganzen graphischen Elemente. Gibt es da eventuell imagemagick als Packet, damit geht es auch. Das kann dann im Makefile aktiviert werden.

Participate now!