GUI universelle ~ = fin à la misère

Pour moi, l'interface graphique idéale est une application qui ne nécessite pas de programmation, de conception, de maintenance et est capable de fonctionner de manière égale avec n'importe quel langage et sur n'importe quelle plate-forme sans aucun réglage. Est-il possible de notre vivant que nous essayions de le comprendre.

Il est facile d'apprendre individuellement quelque chose de Vue / React, JavaFX, Python PyQt, ... mais obtenir des données et interagir avec le zoo du logiciel de manière simple et élégante sans penser à l'utilisateur-OS / navigateurs / plates-formes est une tâche non résolue pour ces outils. Je ne veux pas entrer dans le nouveau cadre (même l'ancien, oublié), changer le langage de programmation, ratisser le râteau et me boucher la tête avec des ordures. Je veux programmer exactement ma tâche, sans être distrait par la lutte avec toutes sortes de frameworks GUI. Et j'ai trouvé une solution pour moi.

En tant que protocole d'échange, nous utiliserons Json comme premier format en termes de popularité / compréhensibilité / lisibilité / prise en charge de tous les langages de programmation à un degré ou un autre.

Le serveur envoie des données Json, selon lesquelles l'interface graphique de notre application doit concevoir une image qui satisfait les spécifications d'une belle interface graphique. Google avec son Material Design est aujourd'hui la norme, alors prenez-le.

Les exigences pour une interface graphique moderne incluent la présence d'éléments standard, tels que des boutons, des champs de saisie, des tableaux, etc. Estimons comment utiliser l'ensemble minimal de conventions pour indiquer à l'interface graphique que nous avons besoin de certains éléments à l'écran. En voici les principaux:

• Bouton sans état {'name': 'Push me'}. Si l'élément ne contient qu'un nom, alors c'est un bouton.
• Le champ de saisie est {'name': 'Edit me', 'value': ''} car la valeur de type est une chaîne.
• Le bouton du sélecteur est {'name': 'My state', 'value': false} car le type false est booléen.
• Sélectionnez dans la liste {'nom': 'Changer quelque chose', valeur: 'choix1', options = ['choix1', 'choix2', 'choix3']}
• {‘name’:’Image, ‘url'’: ’..’, ‘width’: .., ‘height’:… }
• {‘name’:’My table’, 'headers'=[‘Name’, ‘Synonym’], rows = [
  [‘young’, ‘youthful’],
  [‘small’, ‘ meager’],
  ...]
  }
  

Pour la personnalisation, vous pouvez définir le type d'élément sur {type: 'ButtonSwitcher'} si le type sélectionné automatiquement par JSON ne vous convient pas. Cela est possible lorsque le même JSON peut être affiché de plusieurs manières. Par exemple, «Sélectionner dans une liste» peut être représenté comme un champ de saisie avec une liste déroulante, ou il peut également s'agir d'un ensemble horizontal de boutons, dont l'un est actif et correspond à la valeur actuelle.

Avec un petit nombre d'options, il est logique d'utiliser automatiquement l'option de bouton, avec un grand nombre (plus de 3) - un champ de sélection d'entrée. Notre interface graphique elle-même choisit la meilleure façon de rendre, mais si vous en avez vraiment besoin - tapez: ... pour vous aider. Normalement, le type n'est pas nécessaire et le concepteur automobile doit faire face à lui-même.

Complétons l'image en détail:

• si le nom ne doit pas s'afficher à l'écran, il doit commencer par _;
• - , ‘icon’: ‘ Material Design ’; push - {‘name’: ‘_Check’, ‘icon’: ‘check’}
• , Viewers, , ‘colors’, ‘params’,… // . — , .

Pour le regroupement logique des éléments, nous introduisons le concept d'un bloc qui regroupe les éléments logiquement liés dans un bloc visuel.

{'name': 'Block 1', 'elems': [{'name': '_Check', 'icon': 'check'}, ...]}
Dans le bloc, tous les éléments doivent avoir des noms uniques, car ils sont id .

Normalement, les blocs sont construits horizontalement s'ils ne peuvent pas tout contenir sur l'écran (ils ont démarré l'interface graphique de l'application sur un mobile, par exemple), le concepteur automatique les masque, mais ajoute des icônes à la barre d'outils pour les ouvrir d'un simple toucher. Cela vous donne la possibilité de travailler avec une interface graphique complexe, même sur de petits écrans.

Le premier niveau de description est l'écran. Il ressemble à {'name': 'Screan', les blocs: [..], le menu: [{'name': 'Screen', 'icon': ..,}, ..], 'toolbar': [JSON set - éléments (boutons, champs, etc.)]}

Ajoutez les détails d'implémentation de l'uniGUI conditionnel qui prend en charge notre protocole JSON. Il s'agit d'un processus distinct qui communique avec le serveur de données Websocket et fournit l'affichage de ses données avec un rapport ultérieur de toutes les mises à jour de ces données qui sont importantes pour le serveur.

Lors de la connexion au serveur, uniGUI s'attend à recevoir Screen. Après l'avoir reçue, il conçoit et dessine les informations résultantes de manière optimale pour l'écran actuel de l'utilisateur, puis il attend une réaction de l'utilisateur et du serveur. À partir de l'image de données construite, le serveur reçoit un flux de messages JSON qui décrivent entièrement ce que l'utilisateur a fait. Ils ont la forme ['Block', 'Elem', 'type of action', 'value'], où 'Block' et 'Elem' sont les noms du bloc et de l'élément, value est la valeur de l'événement.

Le serveur peut soit accepter la modification, soit les annuler en envoyant une fenêtre d'informations sur l'écart. Il peut ouvrir une boîte de dialogue, qui est décrite comme un bloc, et en a d'autres. le paramètre «boutons», qui décrit les boutons de la boîte de dialogue. Le client affiche instantanément les données actuelles du serveur et leurs modifications. Seuls les objets modifiés par le serveur sont envoyés. Pour recevoir les événements et assurer leur traitement, nous allons créer une couche Websocket (framework), qui traduira automatiquement les messages en appels aux gestionnaires associés à nos données (objets).

Toute la magie du serveur se résume au fait que nos données affichées doivent être liées à la couche de manière à assurer leur traduction automatique en JSON et à rappeler les notifications de l'activité de l'utilisateur sans aucun codage. Comme cela dépend des capacités d'un langage particulier, pour chaque langue, la couche peut avoir différentes options, à la fois architecturales et spécifiques.

Par exemple, dans un cas, la couche a un dossier de captures d'écran, chacun des modules dans lequel a une description d'un écran en Python. Au démarrage, la couche lit les écrans, donne à l'utilisateur une priorité globale = 0. Toutes les données sont transmises automatiquement à l'aide de jsonpickle. Les éléments complexes ont leur propre «intelligence», supprimant le soin des détails du programmeur. Par exemple, une table reçoit un ensemble de lignes dans lesquelles, par défaut, la ligne id peut être absente lorsque le nombre de données dans la ligne == le nombre d'éléments dans les en-têtes. Dans ce cas, lorsque l'utilisateur sélectionne une ligne ou modifie son contenu, le serveur envoie l'identifiant à l'index en ligne comme identifiant ee. Si le nombre de données dans la ligne est supérieur à celui des en-têtes, le dernier élément des lignes est interprété comme id et c'est lui qui est envoyé au serveur. Une telle automatisation simplifie considérablement la vie là où vous n'avez pas besoin de détails,mais si vous en avez soudainement besoin, il est disponible de la manière la moins laborieuse.

La tâche de fournir une traduction automatique en JSON, suivant un format qui occupe une ou deux pages, est complètement résolu dans n'importe quelle langue (je l'espère).

Afin de ne pas discuter de l'applicabilité de cette approche pour des applications complexes, voici des captures d'écran telles que décrites par uniGUI écrites en flutter. Le choix s'est porté sur lui pour les multi-plateformes et le manque de couches supplémentaires comme JS / chrome. Dans le flutter moins, vous pouvez noter la prise en charge dégoûtante du bureau et la faible qualité du code de la couche supérieure (éléments GUI), une architecture désagréable pour les mises à jour ponctuelles et la gestion des éléments en tant que données, qui, cependant, est traitée.



L'interface graphique de l'application de flux de messages -> serveur ressemble à ceci:

flutter: [Glossaire, termes, =, 658]
flutter: [_Details, Links, @, @Folliculitis]
flutter: [_Details, Links, @, @Adolescent]
flutter: [toolbar, _Back, =, _Back]
flutter: [toolbar, _Forward, =, _Forward]
flutter: [toolbar, _Back, =, _Back]
flutter: [_Details, _Status, =, Virtual]
flutter: [_Details, _Status , =, Stable]
flottement: [_Détails, Liens, @,Inflammation]
flutter: [_Details, _Status, =, Virtual]
flutter: [_Details, _Status, =, Stable]
flutter: [toolbar, _Back, =, _Back]
flutter: [_Details, Links, @, @Folliculitis] Y

aura-t-il ralentissez une telle interface graphique lorsque vous attendez des événements du serveur. Non, car l'interface graphique fonctionne en mode de notification du serveur, réagissant à toutes les actions de l'utilisateur comme une interface graphique locale normale. Par défaut, il considère le silence du serveur sur les actions des utilisateurs comme OK. Lors du changement d'écrans, il est clair que sa description doit venir. Il peut y avoir un délai par rapport à l'interface graphique intégrée de l'application c typique.

Total. Il est possible aujourd'hui, sur les outils actuels, de créer une interface graphique qui supprime 90% du code de service morne standard et sans se soucier où et comment cela fonctionnera. Au moins pour les applications commerciales / scientifiques. Cet article est une preuve de concept que la création d'un navigateur d'application conditionnel est non seulement possible, mais nécessaire.