UX: Layout Designer / GUI

Ja, da hat @ssnoopy recht: ich bin kein Programmierer; so gesehen ist mAirList immer noch eine One-Man-Show.
Aber ich bin (nicht nur) dazu da, dass Torben endlich mal wieder zum programmieren kommt. :sunglasses:

Das mit dem Layout-Designer ist so eine Sache für sich.
Im Ergebnis kommt eine statische Datei mit festen Werten dabei heraus - die layout.ini, die nach einer frischen Installation erst dann geschrieben wird, wenn ich den Layout-Designer anwende und die Werte dort auch speichere:

[Browser]
Left=0
Top=0
Width=200
Height=100
ZOrder=0
Detached=off

[Cartwall]
Left=100
Top=100
Width=200
Height=100
ZOrder=5
Detached=off

[Player0_0]
Left=60
Top=60
Width=200
Height=100
ZOrder=3
Detached=off

[Player0_1]
Left=80
Top=80
Width=200
Height=100
ZOrder=4
Detached=off

(usw.)

Problem: Einmal festgeschrieben, bleiben sie so. Angepasst an die Bildschirmgröße / -auflösung. Und genau das ist die Crux an der Nummer: Die Werte sind nicht relativ.

Möchte ich alles zurücksetzen, klicke ich auf “Automatisches Layout”, das nichts anderes macht, als die layout.ini wieder zu löschen.

Automatisches Layout

In dem Fall werden, wie beim ersten Start, bestimmte Elemente nach einer festen Vorgabe an den Bildschirm angepasst.
Nur: Das sieht auf meinem Laptop ganz anders aus als wenn ich den Laptop an meinen großen Bildschirm anschließe. Und spätestens da ist’s Essig mit meinen Absolutwerten aus der layout.ini.

Das kommt aus der Urzeit von mAirList, vielleicht sogar der v1.x oder eher der v2.x.
Sei’s drum, damals™ gab es noch gar keinen Layout-Designer.
Also haben wir uns im Grunde einen Zettel gemalt, wie unser Layout aussehen sollte, das mit den Pixeln ausgerechnet und die Werte dementsprechend händisch in die layout.ini eingetragen. Danach erfolgte der Realitätscheck.

  • Dass wir heute einen vergleichsweise komfortablen Layout-Designer haben, ist großartig.
  • Ob sich die Werte des automatischen Layouts auf ihn übertragen lassen: Unklar.
  • Welches die richtigen Startpositionen für die verschiedenen Bildschirmobjekte sein sollten (es können ja noch selbst definierte hinzukommen):
    Nicht eindeutig für alle Anforderungen zu lösen.

:man_shrugging:

Jau, das verwirrt denke ich die meisten Nutzer beim ersten Öffnen des Layout-Designers… Ich habe ihn vor Schreck das erste Mal wieder neu gestartet weil ich dachte, dass was falsch gelaufen war.

WYSIWYG ist halt schwierig, wenn plötzlich alle Elemente als Stapel in einer Bildecke liegen und man keine echte Vorlage SIEHT, auf der man aufbauen/die man verändern kann…

1 Like

Ich fände es in der Tat auch ein sehrhilfreiches Feature, sehe aber die Komplexität in dieser Aufgabe, da wir ja je nach Bildschirm mit völlig unterschiedlichen statischen Positionswerten starten müseen.

Das würde ich auf gar keinen Fall automatisch beim ersten öffnen durchführen. Sicherlich könnte man einfach as vorhanden sein einer layout.ini abfragen und darauf reagieren aber was, wenn der Layoutdesigner gerade gar nicht im Vollbild Modus getartet ist oder auf einem “falschen” Monitor?

Es bräuchte also einen Button der sagt: Jetzt bitte das default Layout festschreiben. Der dann alle Werte einmal weg schreibt vom aktuellen Fenster in der aktuellen Position und größe bzw. dies verweigert wenn schon eine Layout.ini besteht. Denn ich sehe schon dir Supportrequests: “Ich habe auf den Knopf gedrückt und jetzt ist mein Layout weg, wie bkomme ich das zurück? :sob:

Okay, aber wenn ich mAirlist das erste Mal nach der Installation starte, funktioniert das automatische Anordnen des Standard-Layouts ja auch irgendwie, egal ob im Vollbild oder kleinerem Fenster. :face_with_raised_eyebrow:

Na gut, nehmen wir an, Torben kann die Positionen aus dem automatischen Layout in die layout.ini übertragen (die ja auch erst unmittelbar vor dem Öffnen des Layout Designers erstellt und mit den Werten gefüttert werden muss - vorher gibt es sie gar nicht), dann kann ein Standard-Layout zu Beginn so aussehen:

Das ist jetzt eine 1920*1032 px-Auflösung… an was kleineres mag ich gar nicht denken.

Das funktioniert nicht nur beim ersten Start sondern es wird ständig neu angepasst, auch wenn man während mAirlist läuft, die Fenstergröße ändert.

Es gibt also keine absoluten Positionen, zu keinem Zeitpunkt. Alle Positionen werden immer dynamisch berechnet.

Ich habe sehr lange Zeit mAirlist auf 1280x1024 laufen lassen. Eine durchaus brauchbare Auflösung.
Aus meiner aktuellen Praxis sehe ich ausserdem, dass Full-HD immer noch nicht als minimum-Standard durchgesetzt ist.

Richtig lustig wird es dann bei 2k oder 4k Displays mit DPI Scaling.

1 Like

mmmhja, wobei ich das erste Layout mit drei Cartwall-Buttons persönlich ausreichend fände. Die Playliste würde ich für den Betrieb als deutlich sinnhafter in ausreichender Höhe befinden…

Als ich kürzlich aus Platzgründen beim neuen Setup von einem 27-Zöller (2160 x 1440) und 24-Zöller nun auf zwei 22-Zöller mit nicht-HD ( 1680x1050) als Hauptmonitore umgestiegen bin, musste ich mit Erschrecken feststellen, dass es mich absolut nicht störte.

Im Gegenteil, für die Playliste, Datenbankfenster und zwei Player reicht es dicke, denn das PL-Fenster war einfach nur unnötig breit vorher…

Anderes Extrem: In einem Vereinsstudio stehen nun zwei 32-Zoll-Monitore nebeneinander, knapp 80 Zentimeter vom Moderator entfernt, weil auch ältere Moderatoren noch was erkennen können sollen. Da bewegt sich der Fortschrittsbalken so schnell, dass man das Gefühl hat, man stünde an der Autobahn… :crazy_face:

Schon sind wir beim ersten Haken des Konzepts: Sagen wir mal, ein durchschnittlicher Benutzer der Webstation oder eines Airlite möchte sich sein Layout gemäß der A/B-Tasten (zumindest teilweise) für die Cartwall gestalten, dann muss der sich seine Cw doch schon von Anfang an anders generieren.

Dann geht es nicht mehr um “fände ich ausreichend”, sondern um “mit welchen Ausmaßen und an welchem Platz soll die Cartwall analog zu meinem Pult im Layout erscheinen?”.

Es geht an der Stelle doch um die individuelle Praxis.

Worüber fahren denn die Leute ihre Sendung standardmäßig? Über die Cartwall oder die Playliste?

Bei Deinem Layoutvorschlag sehe ich aber genau wieviele Titel der Playliste? :upside_down_face:

Und wieviele User starten eigentlich gleich mit Webstation oder Airlite? Ihr habt da vielleicht genauere Zahlen durch die Lizenzen.

Dass im Anfangslayout dermaßen viele Cartwall-Buttons statt einem ausreichend langen Playlistfenster sein müssen bezweifle ich dann doch.

Und niemand spricht Usern ab, individuell zu sein. Dafür gibbet ja das Standardlayout, von dem man starten kann…,

Genau so würde ich das (wäre ich neuer mAirList-Nutzer) erwarten. Nicht mehr und nicht weniger. Ich finde, es ist einfacher, wenn man darauf aufbauen kann - anstatt erstmal das Standard-Layout halbwegs nachzubasteln, bis man einigermaßen kapiert hat, wie das funktioniert. Und man hätte eine Rückfallebene, falls man sich verzettelt hat.

Ich verstehe gerade nicht, warum nun ein neues Standard-Layout ins Spiel gebracht wird. Es GIBT ja ein Standard-Layout, und das sollte halt möglichst auch im Designer als Start zu sehen sein, um darauf aufbauen zu können.

War das nicht eigentlich der Tenor/Wunsch

des Threads?

Genau das meine ich ja auch… :+1:

1 Like

Heyho.

Ich weiß nicht ob das eine Relevanz hat. Ich habe von mAirlist die Home Studio Light auf meinem Laptop, der hat natürlich eine andere Bildschirmauflösung wie mein Computer. Es ist doch eigentlich so, dass wenn man mAirlist das erste Mal öffnet das Standart Layout angezeigt wird, kann es dann nicht möglich gemacht werden, dass dann einfach automatisch eine layout.ini mit den Werten die beim erstmaligen Öffnen von mAirlist geschrieben werden? Irgendwoher müssen die Werte von der 1. Öffnung ja kommen.

Vielleicht habe ich den Thread auch nicht richtig verstanden. :man_shrugging:t3::sweat_smile:

1 Like

Wie ich schon weiter oben zu erklären versuchte: Es gibt eben KEIN Standardlayout, Standardmässig gibt es ein dynamisches Layout, welches auf jeder Bildschirmauflösung andere Koordinaten je Element hat.

Also, um die Problematik noch einmal zu erklären und ein paar Einblicke in die innere Architektur zu geben:

Das Hauptfenster (MainForm) existiert im Programmcode in drei (jeweils von der gleichen Basisklasse abgeleiteten Ausprägungen:

  1. Variante “AutoMain”, für das automatische Layout (keine layout.ini vorhanden). Hier gibt es tatsächlich ein System aus ineinander verschachtelten Panels (ähnlich wie von @manuelmeister im Ursprungspost skizziert), die teilweise feste Größen haben, teilweise so eingestellt sind, dass sie sich je nach Fenstergröße den übrigen verfügbaren Platz greifen (in Delphi das sog. “Alignment”); manche auch mit Splittern dazwischen. Diese Panels sind zum Teil schon fest im Quellcode über den Delphi-Form-Designer definiert, teilweise werden sie aber auch erst dynamisch beim Programmstart erzeugt, je nachdem, wie viele Player, Bildschirmobjekte etc. man konfiguriert hat, ob die Cartwall mit im Hauptfenster liegt oder nicht, und so weiter. Insgesamt ein sehr komplexes System, das über die Zeit gewachsen ist und noch erstaunlich zuverlässig funktioniert :wink:

  2. Variante “LayoutMain”, beim Vorhandensein der layout.ini. Hier liegen alle GUI-Elemente “flach” auf dem Hauptfenster und werden ausschließlich über die Pixel-Koordinaten aus der layout.ini positioniert.

  3. Variante “DesignerMain”, wenn mAirList mit -mode designer gestartet wurde; entspricht “LayoutMain”, nur das zusätzlich noch das Fenster mit den Objekteigenschaften sowie die Punkte zum Verschieben/Skalieren angezeigt werden.

Wichtig daran zu wissen: Welche Variante benutzt wird, also wohin das Programm “abbiegt”, entscheidet sich direkt beim Programmstart anhand des Vorhandenseins der layout.ini bzw. des Kommandozeilenparameters. Deswegen kann man auch nicht im laufenden Betrieb zwischen automatischem und festem Layout wechseln.

Zweite Erkenntnis: Es gibt nicht “das” Standard-Layout, sondern neben der Fenstergröße hängt das Standard-Layout von AutoMain sehr stark von der Konfiguration ab (Bildschirmobjekte, Anzahl-Player, weitere Konfigurationsoptionen, etc.).

Diese beiden Punkte sind die Gründe, warum der Layout-Designer beim erstmaligen Start nicht mit einem “Standard-Layout” starten kann: An das echte kommt er nicht heran (weil dazu das Programm in der Variante “AutoMain” hätte gestartet werden müssen), und andererseits ist es auch zu dynamisch bzw. konfigurationsabhängig, um als “Vorlage” irgendwo im Programmcode hinterlegt sein zu können.

Natürlich könnte man mit relativ einfachen Mitteln eine Funktion schaffen, die - während die Variante AutoMain läuft - einmal die aktuellen Pixel-Koordinaten aller beteiligten Objekte abliest und in eine neu erzeugte layout.ini schreibt. Wobei ich auf Anhieb nicht weiß, wo in der GUI/Menü man so eine Funktion sinnvollerweise unterbringen sollte. Wenn jemand eine schlaue Idee hat, immer her damit.

Was die ursprüngliche Anregung von @manuelmeister angeht: Ja, natürlich habe ich schon darüber nachgedacht, und zwar nicht nur einmal. Leider ist das alles sehr komplex und, mangels fertiger Delphi-Komponenten dafür, sehr aufwändig. Denn natürlich will niemand hinterher solche Layouts von Hand als JSON- oder XML-Dateien schreiben, sondern ihr möchtet vermutlich einen graphischen Editor dafür, richtig?

Die sich aus AutoMain ergebenden Koordinaten irgendwo ablegen sowie die Information, daß zuletzt AutoMain am Start war. Falls das der Fall ist, beim Start des Layout-Designers eine Abfrage Letztes Layout übernehmen? einbauen. Falls Ja, eine layout.ini aus den abgelegten Koordinaten schreiben, falls Nein, Start wie gehabt.

In einem Menüpunkt der Konfiguration, der nur auftaucht, wenn ich sie aus dem laufenden mAirlist aufrufe. Irgnedwo im Bereich GUI.

Wortklauberei. Dann nenne es meinetwegen “Standardynamischeslayout”…

Was damit gemeint ist, ist hier ja noch mal erklärt worden.

Oben habe ich erklärt, warum genau das nicht geht, und warum automatisches und manuelles Layout zwei völlig verschiene Paar Schuhe sind.

Vermutlich meint ihr also dasselbe. Also seid mal wieder Freunde :wink:

Die Idee hatte ich auch schon, und das wäre wohl der beste Ansatz.

Schnelle Umsetzung scheitert im Moment daran, dass das AutoMain-Fenster sich einen Dreck um die Bezeichner der Objekte in der layout.ini schert, diese also schlichtweg nicht kennt und nicht wüsste, unter welchen Namen sie diese speichern soll. Das müsste noch nachgerüstet werden.

Das sind so Programmteile, an denen man sieht, dass die Sottware seit 20 Jahren stetig gewachsen ist. Wäre schön, wenn das alles mal vereinheitlicht wäre, ist es aber nicht.

1 Like