Galerie d'interfaces utilisateur écrites en MQL - page 72

Nouveau commentaire
 
Le temps passe et l'idée d'un éditeur visuel continue de vivre dans mon esprit. Elle ne veut pas me quitter. Et lorsque j'y réfléchis à tête reposée, je me pose à chaque fois la question "quel est le problème ? - Je l'ai déjà créé, c'est juste qu'il n'est pas allumé".

En prolongeant la réflexion, j'en reviens aux mêmes conclusions : les fonctions de base de l'éditeur visuel sont déjà présentes dans mon implémentation, et seuls les outils complexes manquent. Cependant, des choses complexes peuvent être créées grâce au langage de balisage, ce qui, dans la pratique, est beaucoup plus rapide et pratique qu'en mode visuel.

Par exemple, les tableaux et les listes d'arbres - il est long et pénible de les composer manuellement, mais les écrire en code kib est rapide et facile... surtout quand on utilise des modèles. surtout lorsqu'on utilise des modèles. Alors pourquoi s'embêter à inventer des outils d'édition visuelle encombrants pour les tableaux et les listes alors qu'on peut les construire avec un simple copier-coller ? Ce n'est pas la peine, c'est clair. Mais alors, quel est le problème ?

Il est simple. Il s'agit de combiner le travail du langage de balisage et les capacités actuelles de l'éditeur visuel. Il n'est pas nécessaire d'ajouter quoi que ce soit de nouveau au premier ou au second - il suffit de les combiner de manière à ce qu'ils se complètent mutuellement.

Après avoir sérieusement réfléchi à cette question, je suis arrivé à la conclusion que même si l'occasion se présentait aujourd'hui de passer complètement à la construction d'interfaces graphiques visuelles, je refuserais. La raison en est que je ne veux pas perdre la possibilité d'utiliser des modèles de kib-code et de simples copier-coller d'éléments ou de propriétés dans l'environnement du langage de balisage. C'est un avantage trop précieux. Peut-être pas seulement pour moi, mais pour tous les futurs utilisateurs qui pourront partager leurs développements ou simplement copier des parties de leurs développements précédents. C'est une chose indispensable.

En d'autres termes, il est absolument impossible d'abandonner un langage de balisage au profit d'un éditeur visuel. Je n'avais pas compris avant....

Aujourd'hui, le problème est donc de développer un système de combinaison harmonieuse des capacités du langage et de l'éditeur visuel. Et en fait, techniquement, c'est assez facile à faire. (1) Premièrement, toutes les fonctions nécessaires de l'éditeur visuel ont été écrites et testées il y a plusieurs années, (2) et deuxièmement, au cours des derniers mois, les mécanismes clés du langage de balisage ont été bien renforcés et une mise à niveau majeure a été effectuée avec l'ajout de la gestion de l'interface logicielle. En d'autres termes, tout est prêt pour l'intégration et la fusion, et il ne reste plus qu'à réfléchir au concept d'interaction sans conflit des deux fonctionnalités dans le processus de modélisation et de construction d'une interface graphique.

D'un point de vue conceptuel, le langage de balisage et l'éditeur visuel sont VRAIMENT en conflit.

Plusieurs raisons rendent cette tâche difficile :

Rappelons que les éléments et les fenêtres de l'interface graphique sont écrits en code de manière standard, mais qu'ils peuvent également être créés dans un éditeur visuel, comme le montre le gif ci-dessus.

1) Dans le premier comme dans le second cas, la fonctionnalité du constructeur construit le noyau graphique, bien que de manière différente, mais comme les capacités de l'éditeur visuel sont plus faibles que celles du langage, les éléments créés n'acceptent pas un ensemble complet de paramètres de la part de l'utilisateur par l'intermédiaire de l'éditeur. Les paramètres peuvent être complétés par l'écriture d'un éditeur, mais le langage de balisage devient alors inutile, et c'est une mauvaise chose, car il n'est pas possible de s'appuyer sur des modèles de code. On ne peut pas abandonner le langage de balisage, point final.

2) Lorsque l'on crée de nouveaux éléments et de nouvelles fenêtres en mode visuel, le langage de balisage ne les "voit" pas. En d'autres termes, le langage de balisage n'est pas mis à jour pendant la construction visuelle de l'interface graphique. Rien n'est "ajouté" au code kib original. Ce fait conduit à nouveau à la séparation conceptuelle de l'éditeur visuel et du langage de balisage. Il s'agit d'un conflit.

Alors, comment être et que faire dans cette situation ? Quel est le compromis permettant la symbiose de deux puissants outils de construction d'interfaces graphiques ?

Je vais essayer de comprendre la solution :

Point principal : limiter le rôle de l'éditeur visuel dans la modélisation de l'interface, en laissant les caractéristiques du langage inchangées. En pratique, cela signifie :

1. Refuser de créer de nouveaux éléments et de nouvelles fenêtres en mode visuel, car le code de balisage n'est pas mis à jour lors de leur ajout.

2. Laisser la possibilité de modifier les positions et de définir les propriétés des éléments et des fenêtres de l'interface utilisateur via les fenêtres de paramétrage de l'éditeur visuel, en plus des valeurs par défaut et personnalisées de l'utilisateur dans le code kib. Dans ce cas, l'éditeur écrira et enregistrera un fichier spécial contenant les valeurs prioritaires, à partir duquel il les chargera dans le noyau et les attribuera aux éléments. En fait, cela signifie un nouveau type de modèles d'éléments "traités" dans l'éditeur. Ils n'entreront pas en conflit avec les modèles de code kib, mais remplaceront les valeurs des propriétés définies dans ces derniers.

Il s'agit, à mon avis, d'une symbiose efficace entre l'éditeur et le langage de balisage.

P.S. L'ironie est que, techniquement, il est possible de réaliser l'idée de fusionner les capacités de l'éditeur et du langage en quelques jours, et c'est tout à fait réaliste, mais penser à tous les détails de leur intégration et de leur interaction dans le travail de l'utilisateur.... cela prend plus de temps. :)

P.S. Mais la principale conclusion est qu'ils PEUVENT et doivent fonctionner ensemble, en se complétant l'un l'autre.
 
Ce que vous voulez faire va prendre beaucoup de temps, et votre code source ne sera pas disponible. presque personne ne pourra contribuer au développement, vous ne pourrez compter que sur vous-même.
 
hini #:
Ce que vous voulez faire va prendre beaucoup de temps, et votre code source, presque personne ne pourra y contribuer, vous devrez compter sur vous-même. presque personne ne pourra y contribuer, vous ne pourrez compter que sur vous-même.
Je ne suis pas du tout d'accord avec la première affirmation. Le concept d'éditeur visuel n'a pas seulement été pensé il y a 4 ans, mais il est techniquement suffisamment implémenté pour permettre à l'utilisateur d'assembler facilement une fenêtre de paramétrage simple à partir de contrôles de base. Dans le concepteur, par exemple, il y a un balisage informatif avec des dimensions et une grille, un panneau pour définir des propriétés et des fonctions pour enregistrer un projet et imprimer un fichier API, les mêmes fenêtres auxiliaires avec des cadres, des images et des polices. Tout se passe comme dans un langage de balisage.

Cependant, pour compléter l'éditeur visuel, un navigateur de fichiers est indispensable. Il permettra de sélectionner des dossiers pour télécharger ou enregistrer des projets, et la bonne nouvelle est que le navigateur de fichiers est déjà là - je l'ai montré plus tôt sur les pages de la branche - et même s'il a besoin d'être peaufiné, la fonctionnalité de base fonctionne.

En plus du navigateur de fichiers, nous devons développer le concept de modèles similaires à kib-code. Au début, je pensais que c'était impossible, mais la solution s'est avérée extrêmement simple : s'il y a un navigateur de fichiers, l'éditeur visuel sera en mesure d'enregistrer l'interface construite non pas en tant que projet, mais en tant que modèle. Après tout, il s'agit essentiellement de la même chose. En outre, non seulement l'ensemble du projet, mais aussi des fenêtres distinctes de ce projet seront sauvegardés en tant que modèle. C'est facile à faire, car seule une partie du noyau construit est sauvegardée et il peut être chargé dans un autre projet et l'utilisateur sera en mesure d'extraire (en copiant comme indiqué dans le gif ci-dessus) les éléments nécessaires et ensuite d'effacer ce modèle de son projet. J'ai la fonction d'effacer les fenêtres et les éléments. C'est tout.

Les tableaux peuvent être construits en copiant simplement des cellules selon l'exemple des boutons dans le gif ci-dessus. C'est la même chose. La liste des arbres est plus compliquée.... mais ce n'est pas l'essentiel.

Avec beaucoup d'enthousiasme, tout peut être fait en un mois, un mois et demi. Mais en ce moment, je suis occupé à préparer des articles, et ce travail est donc reporté.

Quant à l'affirmation selon laquelle d'autres programmeurs ne pourront pas développer le projet..... oui, ils ne peuvent pas développer le projet directement. Mais ils peuvent proposer des solutions, partager leur expérience, leurs opinions, proposer des fonctions de travail avec la couleur, avec le dégradé. Je suis ouvert à ce type d'interaction et de coopération.
 
Реter Konow #:

...

Cependant, un navigateur de fichiers est absolument nécessaire pour compléter l'éditeur visuel. Il permettra de sélectionner des dossiers pour charger ou enregistrer des projets, et la bonne nouvelle est que le navigateur de fichiers est déjà là - je l'ai montré précédemment sur les pages de la branche - et même s'il a besoin d'être ajusté, la fonctionnalité de base fonctionne.
...


Pour ne rien gâcher, voici comment fonctionne le navigateur de fichiers (à gauche). Il suffit de l'intégrer dans l'éditeur.

 

Cette vidéo montre la création de la fenêtre de paramétrage dans l'éditeur visuel de MT5. Elle vous permet de juger approximativement du degré d'achèvement de l'éditeur.


 
hini #:
Ce que vous voulez faire va prendre beaucoup de temps, et votre code source ne sera pas disponible. presque personne ne pourra contribuer au développement, vous ne pourrez compter que sur vous-même.
Je me demande dans quel but vous avez écrit ce billet. :) Je me pose juste la question.

Peut-être, comme beaucoup d'autres, essayez-vous de me faire prendre conscience de la futilité des efforts et des aspirations..... de me faire prendre conscience de l'impossibilité d'atteindre mes objectifs... peut-être essayez-vous de me montrer que vous connaissez une autre voie. ou Dieu sait quoi d'autre.

Mais je vais être honnête : cela n'a pas d'importance. Je vais écrire les articles et terminer l'éditeur visuel comme je l'avais prévu. Et que cela reste un "cheval sphérique dans le vide" inutile pour tout le monde. Qu'il en soit ainsi.

Pour moi, c'est une étape importante du développement.

Permettez-moi d'insister : pour moi, il s'agit d'une étape essentielle du développement.

Par conséquent, l'éditeur "sera". Indépendamment de mon, de votre ou de n'importe qui d'autre, de mon raisonnement, de ma pensée, de mes arguments, de mes contre-arguments, de mon raisonnement, de mes évaluations, de mes humeurs, de mes soupirs, de mes tremblements de tête, etc.

L'éditeur visuel est ENCORE (terminé).

"Pourquoi", "pour quoi", "comment" et "pourquoi" l'appliquer...ou pas.... laissez chacun décider pour lui-même... POUR LUI-MÊME.

Paix. :)
 
Реter Konow #:
Je me demande dans quel but vous avez écrit ce billet. :) Je me pose juste la question.

Peut-être que, comme beaucoup d'autres, vous essayez de me faire passer un message sur la futilité des efforts et des luttes.... de me faire prendre conscience de l'impossibilité d'atteindre mes objectifs... peut-être essayez-vous de me montrer que vous connaissez une autre voie. ou Dieu sait quoi d'autre.

Mais honnêtement, cela n'a pas d'importance. Je vais écrire des articles et terminer l'éditeur visuel comme je l'avais prévu. Et que cela reste un "cheval sphérique dans le vide" inutile pour tout le monde. Qu'il en soit ainsi.

Pour moi, c'est une étape importante du développement.

J'insiste : pour moi, c'est une étape essentielle du développement.

Par conséquent, l'éditeur "se contentera d'être". Quels que soient mes, vos ou autres raisonnements, réflexions, arguments, contre-arguments, raisonnements, appréciations, humeurs, soupirs, secousses de la tête, etc.

L'éditeur visuel est JUST GOOD (fini).

"Pourquoi", "pour quoi", "comment" et "pourquoi" l'appliquer...ou ne pas l'appliquer..... laissez chacun décider pour lui-même... POUR LUI-MÊME.

Paix. :)

Je ne veux rien dire d'autre, c'est juste une idée ; je te soutiens dans la réalisation de ce que tu veux faire.

----------------------------



<édition par le modérateur> en russe : Je ne veux rien dire d'autre, ce n'est qu'une idée ; je vous soutiens dans la réalisation de ce que vous voulez faire.

 

Peter, je pense que ce que vous faites est fantastique ! Sachez que je vous encourage dans votre entreprise.
Il est trop facile de dire "ne laissez jamais la perfection être l'ennemi du bien", mais c'est plus facile à dire qu'à faire lorsque vous
avez une vision de la façon dont votre projet devrait fonctionner.
J'attends avec impatience les prochains articles, etc. sur la façon dont votre éditeur visuel fonctionnera.
Et sachez qu'un bon éditeur visuel ne sera jamais un "cheval sphérique inutile dans le vide".

Cordialement

Doug

 
hini #:

Je ne veux rien dire d'autre, ce n'est qu'une idée ; je vous soutiens dans la réalisation de ce que vous voulez faire.

----------------------------



<édition par le modérateur> en russe : Je ne veux rien dire d'autre, ce n'est qu'une idée ; je vous soutiens dans la réalisation de ce que vous voulez faire.

Je vous remercie pour votre soutien et votre participation continus, qui m'ont beaucoup aidé à gérer ce fil de discussion.
 
Douglas Prager projet devrait fonctionner.
J'ai hâte de lire d'autres articles, etc.... sur le fonctionnement de votre éditeur visuel.
Et sachez qu'un bon éditeur visuel ne sera jamais un "cheval sphérique inutile dans le vide".

Je vous prie d'agréer, Madame, Monsieur, l'expression de mes salutations distinguées,

Doug

Merci beaucoup Douglas pour vos paroles inspirantes. Je sais que lorsque les gens se débarrassent avec conviction des critiques défaitistes, des aspirations dévalorisantes et des idées rabaissantes, ils atteignent ensemble les plus hauts sommets !
1...656667686970717273747576777879...83
Nouveau commentaire