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

 
Реter Konow #:
...
4. La base conceptuelle de l'éditeur vis.est bien pensée, et la base technique a été écrite et testée il y a 4 ans. On peut dire que l'éditeur est à l'aube de sa première version.
Ce point mérite d'être précisé.

L'éditeur visuel (VE) requiert le minimum de fonctionnalités nécessaires pour être mis en œuvre. Examinons d'une manière générale ce qu'elle est.

Base fonctionnelle de l'éditeur visuel :

1. interactions des éléments éditables et modifiables

2. Séparation du noyau graphique en une zone réservée au personnel et une zone réservée aux utilisateurs. Les éléments d'édition et les éléments modifiables doivent se trouver dans des parties différentes du noyau, les premiers dans la zone du personnel, les seconds dans la zone de l'utilisateur.

3. Les fonctions de création et de suppression d'éléments et de fenêtres devraient fonctionner avec la partie utilisateur du noyau et être appelées par des éléments de la partie standard.

4. Fonctionnalité de sauvegarde de la partie personnalisée du noyau après l'édition de l'interface graphique.

5. Chargement de la partie sauvegardée du noyau (projet) à partir d'un fichier, afin de redessiner et d'affiner le projet.


C'est le minimum nécessaire pour un éditeur fonctionnel.


Ce qui est déjà implémenté :

1. Interaction entre les éditeurs et les éléments modifiables.

Les éditeurs ont deux propriétés spécifiques : Target_object et Target_property. Lorsque l'utilisateur clique sur un élément modifiable, celui-ci est mis en évidence. À ce moment-là, les éléments de l'éditeur prennent les valeurs de propriété de l'élément modifiable dans leurs paramètres en fonction de leur propriété Cible_propriété et les affichent par le biais de leur autre propriété spéciale, Propriété_sortie. Ainsi, si Target_property est la couleur de l'élément, Output_property peut être soit du texte affichant le nom de la couleur de l'élément modifiable, soit la couleur de base de l'élément éditeur, qui change en conséquence.

Il existe de nombreuses variantes d'interconnexion de ces éléments, mais la mise en œuvre technique n'est pas une tâche difficile et est assez simple.

2- Le constructeur dispose désormais de son propre fichier API interne, ce qui facilite l'utilisation de la fonctionnalité de ses propres fenêtres de personnalisation à l'aide de fonctions enveloppantes et d'événements GUI entrants.

3- De plus, le constructeur peut être chargé de deux manières : directement depuis le noyau, en contournant le processus d'interprétation du kib-code, ou de manière standard, via l'interprétation du kib-code. Grâce à cela, le temps de chargement du constructeur sur le graphique est passé de ~1,5 seconde à ~16 - 32 millisecondes. De plus, grâce au chargement à partir du fichier du noyau, nous avons réussi à nous débarrasser des avertissements liés au kib-code. Mais ce n'est peut-être qu'une bagatelle par rapport aux perspectives. Le principal avantage du chargement à partir d'un noyau prêt est la possibilité de "compléter" des parties de noyau prêtes à partir d'autres fichiers, qui peuvent être des modèles de fenêtres ou des groupes d'éléments nécessaires au travail de l'utilisateur. Il n'y a qu'un pas à franchir.

4. Les dossiers et les fichiers du constructeur sont entièrement traduits en anglais. L'architecture a subi d'énormes changements.

Mon objectif principal est de créer la fonctionnalité minimale de l'éditeur qui vous permet de construire l'éditeur de l'intérieur, en contournant le langage de balisage.

 
J'ai annoncé précédemment la date limite de publication de la prochaine version : le 28 novembre. En raison de la réorientation de l'éditeur visuel, je dois reporter la publication de la mise à jour au 10 décembre. Pour le reste, le programme approuvé précédemment reste inchangé. L'éditeur sera téléchargé sur kodobase, la branche des modèles sera ouverte et le premier article sera écrit.

Les deux derniers points doivent être expliqués.

1) La branche des modèles de fenêtres d'interface utilisateur sera ouverte comme prévu, mais au lieu d'images d'interface utilisateur avec des fragments de code kib, des images d'interface utilisateur seront postées avec des fichiers UIDATA contenant des informations techniques et des fragments de noyau nécessaires pour reproduire les modèles dans l'éditeur.

2) Après la publication, j'espère écrire un article sur l'éditeur. J'y présenterai les informations nécessaires pour démarrer. À l'avenir, lorsque le sujet de l'éditeur sera épuisé, et s'il y a de l'intérêt et de la demande, je pourrai publier des articles sur les applications de trading avec interface graphique.

Ainsi, presque rien n'a changé dans les plans. Seuls la date et le sujet ont changé.

P.S. Je pense avoir pris la bonne décision.

Mon objectif principal est de susciter la demande et de faire de l'éditeur un outil populaire. C'est beaucoup plus difficile à réaliser avec un langage de balisage. J'ai déjà eu l'occasion de le constater sur les pages de ce fil. Répétez cette méthode - publiez des codes, des images et des tutoriels - mais avec encore plus d'efforts, et attendez-vous à ce que le résultat soit différent et que les gens se précipitent pour apprendre le langage..... Non, ce n'est pas la peine.

J'espère que l'éditeur sera plus utile. Mais nous verrons bien. :)

 
Реter Konow interface graphique.

Ainsi, presque rien n'a changé dans les plans. Seuls la date et le sujet ont changé.

P.S. Je pense avoir pris la bonne décision.

Mon objectif principal est de susciter la demande et de faire de l'éditeur un outil populaire. C'est beaucoup plus difficile à réaliser avec un langage de balisage. J'ai déjà eu l'occasion de le constater sur les pages de ce fil. Répétez cette méthode - publiez des codes, des images et des tutoriels - mais avec encore plus d'efforts et attendez-vous à ce que le résultat soit différent et que les gens se précipitent pour apprendre le langage..... Non, ce n'est pas la peine.

J'espère que l'éditeur sera plus utile. Mais nous verrons bien :)

Je pense que l'éditeur est un meilleur choix pour un public plus large. La plupart des gens ne sont pas des techniciens et veulent un moyen facile de produire des résultats.

Je pense que l'éditeur est une excellente idée et que si vous y parvenez, ce sera fantastique. Vous pourriez même le vendre en tant que bibliothèque sur le marché. Il semble criminel qu'une telle chose soit mise à disposition gratuitement puisque vous y consacrez tant de temps et d'efforts.

Je soutiens totalement votre décision de faire un éditeur
 
Levi Dane Benjamin #:
...

Je pense que l'éditeur est un meilleur choix pour un public plus large. La plupart des gens ne sont pas des techniciens et veulent un moyen facile d'obtenir des résultats.

Je pense que l'éditeur est une excellente idée et si vous le mettez en œuvre, ce sera fantastique. Vous pourriez même le vendre comme bibliothèque sur le marché. Il semble criminel qu'une telle chose soit disponible gratuitement, après tout le temps et les efforts que vous y avez consacrés.

Je soutiens pleinement votre décision de créer un éditeur
Merci pour votre précieux soutien ! Il est important pour moi de connaître l'opinion des autres afin de ne pas me perdre dans mes conclusions..... et de faire le bon choix.

Vous savez, j'ai pris la décision de ne pas considérer un éditeur visuel comme quelque chose de fantastique. J'ai remarqué qu'inconsciemment, je considère l'éditeur comme moins réalisable. J'essaie donc de le considérer comme une routine de travail. C'est plus facile pour moi de le créer de cette façon. Ce ne sont que des jeux d'esprit. :)

En ce qui concerne la distribution gratuite, c'est une décision réfléchie. Il n'y a pas d'autre solution pour l'instant. Je ne monétiserai pas l'éditeur lui-même, c'est certain. Mais peut-être qu'à l'avenir, s'il y a une demande, je proposerai une fonction payante. Nous verrons bien. :)
 
Le processus de développement de la VE n'est pas figé.

1. La restructuration à grande échelle du concepteur et du moteur est terminée. La nouvelle structure d'organisation des dossiers et des fichiers est mise en place.

2. La fonctionnalité de l'éditeur est bien pensée. Les préparatifs pour l'écriture sont en cours.

3. La mise en œuvre des projets dans l'éditeur est pensée et rédigée.

4. Je dois noter que l'éditeur est devenu absolument clair et compréhensible pour moi. À tel point que j'ai trouvé des parallèles directs avec Kostruktor et que j'ai réalisé qu'il y a longtemps, bien des années, j'étais passé d'un chemin court à un chemin long, parce que je pouvais immédiatement écrire un éditeur visuel en contournant le langage de balisage. Techniquement, j'avais cette possibilité devant moi, mais je ne l'avais pas vue. Je ne l'ai pas comprise et je ne l'ai pas réalisée. Mais c'était simple. Plus simple que de construire un constructeur avec le langage de balisage. Beaucoup plus simple. Mais, hum. c'est ce qui s'est passé.
 
Реter Konow projets dans l'éditeur est pensée et écrite.

4. Je dois dire que l'éditeur est devenu absolument clair et compréhensible pour moi. À tel point que j'ai trouvé des parallèles directs avec Kostruktor et que j'ai réalisé que j'avais abandonné la voie courte pour la voie longue il y a de nombreuses années, parce que j'aurais pu écrire un éditeur visuel en contournant le langage de balisage. Techniquement, j'avais cette possibilité devant moi, mais je ne l'ai pas vue. Je ne l'ai pas comprise et je ne l'ai pas réalisée. Mais c'était simple. Plus simple que de construire un constructeur avec le langage de balisage. Beaucoup plus simple. Mais, hum. c'est ce qui s'est passé.

Nous nous souvenons. Nous attendons. Nous croyons.

 
Très bien. Une attention silencieuse.
 
Tous les deux ou trois jours, j'afficherai l'état d'avancement du développement. L'objectif est simple : tenir les lecteurs du fil de discussion informés. Sinon, il se peut que je disparaisse quelque part et que personne ne sache comment l'affaire progresse.

Et cela se passe bien. Bien sûr, c'est beaucoup de travail. Même pour moi. Mais il est rassurant de savoir que le travail est programmé et planifié.

C'est surtout de la routine. Beaucoup de routine. Après avoir terminé la restructuration globale du concepteur et du moteur, l'éditeur a automatiquement reçu une structure préparée à l'avance, et continue maintenant à se former à l'intérieur de celle-ci. Cela s'est avéré très pratique.

L'éditeur a défini 6 fonctionnalités principales. Elles ont déjà été conceptualisées et mises sur papier. La bonne nouvelle, c'est que 4 de ces 6 fonctionnalités ont déjà été mises en œuvre et qu'il ne sera pas trop difficile de les mettre à jour. La cinquième fonctionnalité fonctionne dans le concepteur, mais nécessite un remaniement pour l'éditeur. Et ce n'est pas difficile. Et la sixième devra être écrite à partir de zéro. Mais ce travail est assez clair, et il n'y a rien d'autre.

Ces fonctionnalités sont la raison d'être de l'éditeur.

J'essaie maintenant de m'affranchir du langage de balisage dans lequel j'écris encore l'interface VE. Son interface graphique s'est avérée... mais je ne vais pas m'en féliciter. ) Dans l'ensemble, ce n'est pas mal. Cependant, écrire des graphiques aussi grands et complexes est vraiment difficile. C'est pourquoi le moment de rompre avec le langage et de passer à l'édition visuelle est si important. Lorsque cela se produira, je construirai l'éditeur dans l'éditeur lui-même, ce qui offrira une vitesse sans précédent et le travail passera en mode turbo. Ce ne sera pas long.

Bien sûr, en mode turbo, il faudra se fatiguer, mais moins. Beaucoup moins.


 
écrire pour quoi
 

Le développement bat son plein. Il y a des questions et des doutes sur l'interface graphique de l'éditeur et comme le projet est public, j'ai voulu consulter les lecteurs. Voici une capture d'écran de l'éditeur à ce stade. J'accepte les conseils, les recommandations et les critiques constructives.



Comme il s'agit de mon premier éditeur visuel, je ne sais pas très bien comment le réaliser. En d'autres termes, à quoi doit-il ressembler ? Il est difficile de tout imaginer d'un seul coup.