[ TAG 435 ][30.05.2022] -Erfolgreich -IAP-20220403-20220403-1150 -Positionierungsproblem

Ich kann über dieses IAP leider nichts konkretes berichten. Jedoch kann ich einige neutrale Abschnitte öffentlich diskutieren.

An diesen IAP ist nichts besonderes es geht um ein User-Interface. Die Methodik, die ich bei den IAP-20220403-20220403-1150 erarbeiten werde, werde ich in Zukunft auf weitere User-Interfaces anwenden.

Ich habe bereits einige Prototypen der ausprobiert bzw. erarbeitet um mir die Schwierigkeiten im Detail anzuschauen und dafür Lösungen zu entwickeln.

Das Prinzip des Aufbaus der GUI besteht aus drei Bausteinen. Bzw. es wird auf drei Bausteine reduziert.

1. NoNSTL - alle Elemente und Eigenschaften müssen definiert sein.
2. DeFSTL - alle Elemente bekommen ihre Default Werte, wenn sie nicht in USERSTL definiert sind.
3. INISTL - alle Elemente werden mit Ihren Eigenschaften werden als GUI-Komponente initialisiert.

Einer der Schwierigkeiten besteht gerade darin, Entscheidungen über Reglungen der geometrische Eigenschaften zu treffen.

Zudem ist dieses Problem auch sehr komplex.

Ich nehme aus dem IAP ein Auszug.

DeFSTL_FNC_FRM

stl_key: GRP02-FRM05

chld: [

    'GRP02-FRM05', 

    'GRP02-FRM05-LBL00', 

    'GRP02-FRM05-LBL01', 

    'GRP02-FRM05-ENT00'

]

Ich denke es ist sinnvoll Levels zu definieren.

LVL-0: GRP02, stl_key = GRP02

LVL-1: FRM05, stl_key = GRP02-FRM05

LVL-2: LBL00, stl_key = GRP02-FRM05-LBL00

LVL-2: LBL01, stl_key = GRP02-FRM05-LBL01

LVL-2: ENT00, stl_key = GRP02-FRM05-ENT00

Ich denke weitere Levels zu definieren würde kein Sinn machen.

Die Kernaufgabe besteht darin, eine Eingabe aufzunehmen. Dazu haben wir ein ENT-Element. Die LBL-Elemente dienen der Beschreibung der einzugebenden Daten.

Prinzip der Positionierung

Im [ FRM ]-Element auf [ LVL-1 ] wird eine Breite und Höhe angegeben.

Eine Frage bzw. ein Punkt an den ich bisher nicht gedacht habe, ist die Ausrichtung. Die Ausrichtung muss angegeben werden, weil sie entscheidet ob die Elemente Horizontal oder Vertikal platziert werden.

Bei einer horizontalen Ausrichtung, wird eine Mindest-Breite definiert, die nicht überschritten werden soll. Diese Mindest-Breite darf nicht in DeFST und in USERSTL unterschritten werden. Werte die unter der Mindest-Breite liegen werden überschrieben.

Bei einer horizontalen Ausrichtung wird die [ FRM ]-Breite durch die Anzahl der Kindel-Elemente geteilt. Die daraus resultierende Breite wird auf die Kind-Elemente angewendet. Der Restpixel wird dem letzten Kind-Element zugeordnet.

Was wäre, wenn die Positionierungslogik mit den geometrischen Problemen nur das [FRM]-Element beinhalten würde.

Die Elemente im LVL-2 würden keine Positionierungslogik oder geometrische Probleme beinhalten. Die Elemente im LVL-2 würden zwar Eigenschaften wie [ x, y, width, height ] besitzen, jedoch verwaltet werden sie von den FRM-Elementen im LVL-1.

Die Elemente im LVL-2 würden zum Beispiel nur Eigenschaften verwalten, wie [ fnt, txt, fg, bg, anchr ].

Die Schwäche dieser Vorgehensweise läge darin, dass wenn man zum Beispiel viele Elemente im [ FRM ] hätte, würde man die Elemente sehr klein machen. Man könnte diesen Effekt auch entgegen wirken, in dem man eine Mindest-Breite einführt. Diese Mindest-Breite wird nicht unterschritten.