Universelle GUI ~ = Ende des Elends

Für mich ist die ideale Benutzeroberfläche eine App, die keine Programmierung, kein Design und keine Wartung erfordert und mit jeder Sprache und auf jeder Plattform ohne Änderungen gleichermaßen arbeiten kann. Ist es in unserem Leben möglich, werden wir versuchen, es herauszufinden.

Es ist einfach, individuell etwas von Vue / React, JavaFX, Python PyQt usw. zu lernen, aber Daten abzurufen und auf einfache und elegante Weise mit dem Software-Zoo zu interagieren, ohne an Benutzer-Betriebssysteme / Browser / Plattformen zu denken, ist eine ungelöste Aufgabe für solche Tools. Ich möchte nicht in das neue Framework (auch nicht in das alte, vergessene) einsteigen, die Programmiersprache ändern, den Rechen harken und meinen Kopf mit Müll verstopfen. Ich möchte genau meine Aufgabe programmieren, ohne vom Kampf mit allen möglichen GUI-Frameworks abgelenkt zu werden. Und ich habe eine Lösung für mich gefunden.

Als Austauschprotokoll werden wir Json als Top-Format in Bezug auf Popularität / Verständlichkeit / Lesbarkeit / Unterstützung in allen Programmiersprachen bis zu dem einen oder anderen Grad verwenden.

Der Server sendet Json-Daten, nach denen unsere App-GUI ein Bild entwerfen soll, das den Spezifikationen einer schönen GUI entspricht. Google mit seinem Materialdesign ist heute der Standard.

Zu den Anforderungen für eine moderne Benutzeroberfläche gehört das Vorhandensein von Standardelementen wie Schaltflächen, Eingabefeldern, Tabellen usw. Lassen Sie uns abschätzen, wie die Mindestkonventionen verwendet werden, um der Benutzeroberfläche mitzuteilen, dass bestimmte Elemente auf dem Bildschirm benötigt werden. Hier sind die wichtigsten:

• Zustandsloser Knopf {'Name': 'Push me'}. Wenn das Element nur einen Namen enthält, handelt es sich um eine Schaltfläche.
• Das Eingabefeld lautet {'name': 'Edit me', 'value': ''}, da der Typwert eine Zeichenfolge ist.
• Die Umschalttaste {'name': 'Mein Status', 'Wert': false}, da der Typ false boolesch ist.
• Wählen Sie aus der Liste {'Name': 'Etwas wechseln', Wert: 'Wahl1', Optionen = ['Wahl1', 'Wahl2', 'Wahl3']}
• {‘name’:’Image, ‘url'’: ’..’, ‘width’: .., ‘height’:… }
• {‘name’:’My table’, 'headers'=[‘Name’, ‘Synonym’], rows = [
  [‘young’, ‘youthful’],
  [‘small’, ‘ meager’],
  ...]
  }
  

Zur Anpassung können Sie den Elementtyp auf {type: 'ButtonSwitcher'} setzen, wenn der von JSON automatisch ausgewählte Typ nicht zu Ihnen passt. Dies ist möglich, wenn derselbe JSON auf mehrere Arten angezeigt werden kann. Beispielsweise kann "Aus einer Liste auswählen" als Eingabefeld mit einer Dropdown-Liste dargestellt werden, oder es kann sich auch um einen horizontalen Satz von Schaltflächen handeln, von denen eine aktiv ist und dem aktuellen Wert entspricht.

Bei einer kleinen Anzahl von Optionen ist es sinnvoll, die Schaltflächenoption automatisch zu verwenden, bei einer großen Anzahl (mehr als 3) - einem Eingabeauswahlfeld. Unsere GUI selbst wählt den besten Weg zum Rendern, aber wenn Sie es wirklich brauchen - geben Sie Folgendes ein: ... um zu helfen. Normalerweise wird der Typ nicht benötigt und der Autodesigner muss alleine zurechtkommen.

Vervollständigen wir das Bild im Detail:

• Wenn der Name nicht auf dem Bildschirm angezeigt werden soll, muss er mit _ beginnen.
• - , ‘icon’: ‘ Material Design ’; push - {‘name’: ‘_Check’, ‘icon’: ‘check’}
• , Viewers, , ‘colors’, ‘params’,… // . — , .

Für die logische Gruppierung von Elementen führen wir das Konzept eines Blocks ein, der logisch verwandte Elemente in einem visuellen Block gruppiert.

{'name': 'Block 1', 'elems': [{'name': '_Check', 'icon': 'check'}, ...]}
Innerhalb des Blocks müssen alle Elemente eindeutige Namen haben, da sie id sind .

Normalerweise werden Blöcke horizontal erstellt, wenn sie nicht auf alle Bildschirme passen (sie haben beispielsweise die App-Benutzeroberfläche auf einem Mobiltelefon gestartet). Der automatische Designer blendet sie aus, fügt der Symbolleiste jedoch Symbole hinzu, mit denen sie mit einem Fingertipp geöffnet werden können. Dies gibt Ihnen die Möglichkeit, auch auf kleinen Bildschirmen mit einer komplexen Benutzeroberfläche zu arbeiten.

Die oberste Beschreibungsebene ist Bildschirm. Es sieht aus wie {'Name': 'Screan', Blöcke: [..], Menü: [{'Name': 'Bildschirm', 'Symbol': ..,}, ..], 'Symbolleiste': [JSON-Set - Elemente (Schaltflächen, Felder, was auch immer)]}

Fügen Sie Implementierungsdetails für die bedingte uniGUI hinzu, die unser JSON-Protokoll unterstützt. Es handelt sich um einen separaten Prozess, der mit dem Websocket-Datenserver kommuniziert und dessen Daten anzeigt und anschließend alle für den Server wichtigen Aktualisierungen dieser Daten meldet.

Bei der Verbindung mit dem Server erwartet uniGUI den Empfang des Bildschirms. Nachdem er es erhalten hat, entwirft und zeichnet er die empfangenen Informationen auf optimale Weise für den aktuellen Bildschirm des Benutzers und wartet dann auf eine Reaktion des Benutzers und des Servers. Aus dem erstellten Datenabbild empfängt der Server einen Stream von JSON-Nachrichten, die vollständig beschreiben, was der Benutzer getan hat. Sie haben die Form ['Block', 'Elem', 'Aktionstyp', 'Wert'], wobei 'Block' und 'Elem' die Namen des Blocks und Elements sind, Wert der Wert des Ereignisses.

Der Server kann die Änderung entweder akzeptieren oder zurücksetzen, indem er ein Infofenster über die Diskrepanz sendet. Es kann ein Dialogfeld öffnen, das als Block beschrieben wird und über zusätzliche Funktionen verfügt. Der Parameter 'Schaltflächen', der die Schaltflächen im Dialogfeld beschreibt. Der Client zeigt sofort die aktuellen Serverdaten und deren Änderungen an. Es werden nur vom Server geänderte Objekte gesendet. Um Ereignisse zu empfangen und deren Verarbeitung sicherzustellen, erstellen wir eine Websocket-Schicht (Framework), die Nachrichten automatisch in Aufrufe an Handler übersetzt, die unseren Daten (Objekten) zugeordnet sind.

Die ganze Magie auf dem Server beruht auf der Tatsache, dass unsere angezeigten Daten so mit der Ebene verknüpft werden sollten, dass ihre automatische Übersetzung in JSON gewährleistet ist und Benachrichtigungen von Benutzeraktivitäten ohne Codierung zurückgerufen werden. Da dies von den Fähigkeiten einer bestimmten Sprache abhängt, kann die Ebene für jede Sprache unterschiedliche Optionen haben, sowohl architektonisch als auch spezifisch.

In einem Fall verfügt die Ebene beispielsweise über einen Screenshot-Ordner, in dem jedes Modul eine Beschreibung eines Bildschirms in Python enthält. Beim Start liest die Ebene die Bildschirme und gibt dem Benutzer eine mit globaler Priorität = 0. Alle Daten werden automatisch mit jsonpickle übertragen. Komplexe Elemente haben ihre eigene „Intelligenz“, wodurch dem Programmierer die Sorgfalt für Details entzogen wird. Beispielsweise empfängt eine Tabelle eine Reihe von Zeilen, in denen standardmäßig die ID-Zeile fehlen kann, wenn die Anzahl der Daten in der Zeile == die Anzahl der Elemente in den Kopfzeilen ist. In diesem Fall sendet der Server die ID als ID an den Index in der Zeile, wenn der Benutzer eine Zeile auswählt oder deren Inhalt bearbeitet. Wenn die Anzahl der Daten in der Zeile eins höher ist als in den Kopfzeilen, wird das letzte Element in den Zeilen als ID interpretiert und an den Server gesendet. Eine solche Automatisierung vereinfacht das Leben dort, wo Sie keine Einzelheiten benötigen, erheblich.Wenn es jedoch plötzlich benötigt wird, ist es am wenigsten arbeitsintensiv verfügbar.

Die Aufgabe, eine automatische Übersetzung in JSON in einem Format mit einer oder zwei Seiten bereitzustellen, ist in jeder Sprache vollständig lösbar (ich hoffe es).

Um die Anwendbarkeit dieses Ansatzes für komplexe Anwendungen nicht zu diskutieren, finden Sie unten Screenshots, wie sie von uniGUI in Flattern geschrieben wurden. Die Wahl fiel auf mehrere Plattformen und das Fehlen zusätzlicher Schichten wie JS / Chrom. Im Flatter-Minus können Sie ekelhafte Desktop-Unterstützung und geringe Qualität des Codes der oberen Ebene (GUI-Elemente) aufschreiben, eine unangenehme Architektur für Punktaktualisierungen und das Verwalten von Elementen als Daten, die jedoch behandelt werden.



Der Nachrichtenfluss der GUI-App -> Server sieht ungefähr so aus:

Flattern: [Glossar, Begriffe, =, 658]
Flattern: [_Details, Links, @, @Folliculitis]
Flattern: [_Details, Links, @, @Adolescent]
Flattern: [Symbolleiste, _Back, =, _Back]
Flattern: [Symbolleiste, _Forward, =, _Forward]
Flattern: [Symbolleiste, _Back, =, _Back]
Flattern: [_Details, _Status, =, Virtual]
Flattern: [_Details, _Status , =, Stabil]
flattern: [_Details, Links, @,Entzündung]
flattern: [_Details, _Status, =, Virtual]
flattern: [_Details, _Status, =, Stable]
flattern: [toolbar, _Back, =, _Back]
flattern: [_Details, Links, @, @Folliculitis]

Wird es geben Verlangsamen Sie eine solche GUI, wenn Sie auf Ereignisse vom Server warten. Nein, da die GUI im Serverbenachrichtigungsmodus arbeitet und auf alle Benutzeraktionen als normale lokale GUI reagiert. Standardmäßig wird die Serverstille bei Benutzeraktionen als OK betrachtet. Beim Wechseln der Bildschirme ist klar, dass die Beschreibung kommen sollte. Im Vergleich zur typischen eingebetteten GUI von App C kann es zu Verzögerungen kommen.

Gesamt. Mit aktuellen Tools ist es heute möglich, eine grafische Benutzeroberfläche zu erstellen, die 90% des tristen Standard-Servicecodes entfernt und sich nicht darum kümmert, wo und wie sie funktionieren wird. Zumindest für Business / Science-Anwendungen. Dieser Artikel ist ein Proof of Concept, dass das Erstellen eines bedingten App-Browsers nicht nur möglich, sondern auch notwendig ist.