Setup-Menü mit dynamischer Breite

Damit kann die zweite Spalte im Extremfall erst rechts vom rechten OSD-Rand beginnen so das sie nicht mehr sichtbar ist.
Sollte man die max. Breite der ersten Spalte nicht auf 2/3 oder 3/4 der OSD-Breite begrenzen?

Quote from kls

Ist das eine theoretische Übelegung oder gibt es einen praktischen Fall? In den Texten vom Core-VDR sehe ich keinen.
Die Texte in der ersten Spalte (und natürlich auch in der zweiten) sollten natürlich so ausgelegt sein, dass alles in das OSD passt.

D.h. du vermutest dass Übersetzer nur eine vorgegebene maximale Länge für diese Texte verwenden(?) Dann solltest Du das für die Übersetzer dokumentieren.

Das ist eher eine theoretische Überlegung und ich denke da auch eher an Plugins als an den Core-VDR. Aber irgendwann schafft es irgendein Plugin bestimmt :-> Das wäre dann aber ein Fehler im Plugin.
Und wenn man jetzt schon bei statischer Spaltenbreite das OSD zu schmal macht, kann man es via OSD auch nicht (bzw. nur unsichtbar) zurück ändern.

Das scheint mir kein sinnvoller Ansatz zu sein. Denn mit dem Patch erscheint beispielsweise das Menü der Skin noPacity völlig ohne zweite Spalte:

Vorher hatte ich mir, weil der Standard zu knapp bemessen war, die Spaltenbreite passend gepatcht:

Automatik macht immer mal Probleme und weniger ist dann oftmals mehr. Warum also wählen wir nicht den im VDR üblichen Ansatz, die Breite der linken Spalte im Setup einstellen zu können? Dann kann es jeder so einstellen, wie es für seine Auswahl von Plugins den besten Kompromiss liefert.

PS: Und einen problematischen Wert mit Ergebnissen wie oben kann man manuell in der setup.conf zurücksetzen.

Kannst du bitte noch eine Lösung posten, bei der ich nicht für jeden A/B-Vergleich den gesamten VDR samt Plugins ständig neu übersetzen muss?

Quote from kls

Na gut, ich kann natürlich vorgeben, dass übersetzte Texte nicht länger sein dürfen als die englischen. Das wird sich aber nicht immer einhalten lassen. Im Zweifelsfall hilft nur ausprobieren.

> Im Zweifelsfall hilft nur ausprobieren.

Weiß nicht. Dass der Übersetzer auch testet ist wohl eher nicht zu erwarten. Und wenn, müssten wir bei jedem Text dokumentieren an welcher Stelle im UI dieser Text verwendet wird. Damit der Übersetzer dann an dieser Stelle testen kann. Erscheint mir insgesamt zu aufwändig.

> ich kann natürlich vorgeben, dass übersetzte Texte nicht länger sein dürfen als die englischen

Englische Texte sind immer recht kurz. Von daher wäre die Vorgabe, dass übersetzte Texte max. 30% länger sein dürfen als englische Texte realistischer.

Und wenn VDR dann noch automatisiert verifiziert (z.B. per DEFINE einschaltbar), dass alle Spalten groß genug für "Englische Texte + 30%" sind, könnten wir wieder mit einer festen Spaltenbreite arbeiten ...

Aus meiner Sicht die beste Lösung

Übersetzern solche Vorgaben machen zu wollen bzw. müssen, erscheint mir etwas weltfremd.

Quote from kls

Kannst du bitte mal in cMenuSetupPage::Display() den Wert von t vor dem Aufruf von SetCols(t) ausgeben und posten?

t = 41 + 5

Keine Ahnung was da vorher war, jetzt sieht es so aus:

Ich meinte im Übrigen ja auch den Vergleich von mit/ohne den Patch.

PS: Ich hatte auch vorher schon make clean / make install über den VDR und alle Plugins laufen lassen…

In skinnopacity wird die Breite der ersten Spalte im Setup-Menu aktuell auf 40 gesetzt. Das gilt dann ja auch noch mit dem Patch von oben, oder wird das dann irgnoriert?
Es sollte also auch mit dem Patch so aussehen, wie im Bild vom Beitrag #14.

Warum es ohne dieses explizite Setzen der Breite, die 2. Spalte verschluckt, kann ich momentan nicht sagen. Ich würde da aber bei Gelegenheit mal recherchieren.

Wenn man erst einmal ein wenig Abstand gewonnen hat, kommen einem oft noch weitere Aspekte in den Sinn:

• Kann man gewährleisten, dass ein solcher Ansatz für alle Skins verwendbar und nützlich ist?
• Wie kann ein solcher Ansatz gleichermaßen für rein textbasierte wie grafische Oberflächen funktionieren?
• Wie wirkt es sich aus, wenn die Schrift bewusst größer gewählt wird, um eine Sehschwäche auszugleichen?
• Macht es Sinn, die Zahl der Zeichen als Maßstab heranzuziehen, sobald ein proportionaler Font verwendet wird? Oder müsste man stattdessen nicht vielmehr die Breite des Textes in Pixeln als Maßstab heranhiehen?
• Wie geht man mit noch immer zu langen Texten um? Die Skin nOpacity etwa scrollt horizontal, sobald der Text des ausgewählten OSD-Elements nicht vollständig dargestellt werden kann. Das lässt sich sicherlich auch in textbasierten oder anderen grafischen Skins entsprechend einrichten, vielleicht sogar als Service in der Basisklasse einbetten.

Sollte man also anstatt zu versuchen, eine optimale Spaltenbreite zu finden, nicht vielleicht einen anderen Ansatz verfolgen? Oder gibt es gar weitere Gedanken und Ideen hierzu in der Community?

Wenn man sich die Diskussion so anschaut, merkt man erst, in was für eine Sackgasse man rennt, wenn man im Jahr 2026 noch versucht, UI-Layouts über die reine Anzahl von Zeichen zu berechnen.

Die Idee, Übersetzern starre Vorgaben zu machen (oder gar "Englisch + 30%" automatisiert zu prüfen), ist gelinde gesagt weltfremd. Sprache lebt, und die deutsche Übersetzung braucht nun mal naturgemäß oft deutlich mehr Platz als ein knackiger englischer Begriff. Das darf nicht das Problem des Übersetzers sein, sondern die UI muss damit klarkommen.

SHofmann legt da im letzten Beitrag den Finger genau in die Wunde:
Solange Skins proportionale Schriftarten (TrueType) verwenden, ist die reine Anzahl der Zeichen (`t = 41 + 5`) als Layout-Basis mathematischer Zufall. Ein "M" braucht dreimal so viel Platz wie ein "i". Ein sauberer Ansatz müsste eigentlich die tatsächliche Textbreite in Pixeln (abhängig vom geladenen Font) ermitteln, anstatt blind Zeichen zu zählen.

Wenn eine Automatik im Core dazu führt, dass bei grafischen Skins wie nOpacity plötzlich die zweite Spalte im Nirvana verschwindet, zeigt das doch nur, dass der starre "One-Size-Fits-All"-Ansatz für den Core nicht funktioniert.

Bevor wir jetzt den Core mit harten Limits für Textlängen verkrüppeln, wäre die von SHofmann vorgeschlagene Lösung – die Spaltenbreite einfach wie gewohnt im Setup manuell einstellbar zu machen – der ehrlichste und stabilste Kompromiss für alle Beteiligten. Das spart auch das ständige Neuübersetzen für jeden A/B-Vergleich.