Galeria de UIs escritas em MQL - página 72

Novo comentário
 
O tempo passa e a ideia de um editor visual continua viva em minha mente. Ela não quer me abandonar. E quando penso nisso em meu tempo livre, sempre me pergunto "qual é o problema? - Eu já o criei, ele só não está ligado".

No prolongamento da reflexão, volto às mesmas conclusões: as funções básicas do editor visual já estão presentes em minha implementação, faltando apenas as ferramentas complexas. Entretanto, coisas complexas podem ser criadas por meio da linguagem de marcação, que, na prática, é muito mais rápida e conveniente do que no modo visual.

Por exemplo, tabelas e listas em árvore - é longo e doloroso compô-las manualmente, mas é fácil e rápido escrevê-las no kib code.... especialmente quando se usam modelos. Então, por que se preocupar em inventar ferramentas de edição visual complicadas para tabelas e listas quando você pode criá-las com um simples copiar e colar? Não faz sentido, isso está bem claro. Mas então qual é o problema?

É simples. A tarefa é combinar o trabalho da linguagem de marcação e os recursos atuais do editor visual. Não é necessário acrescentar nada de novo ao primeiro ou ao segundo - eles só precisam ser combinados de forma que se complementem.

Depois de refletir seriamente sobre essa questão, cheguei à conclusão de que, mesmo que agora haja uma oportunidade de mudar completamente para a construção de GUIs visuais, eu recusaria. O motivo é que não quero perder a oportunidade de usar modelos de código kib e copiar e colar elementos ou propriedades no ambiente da linguagem de marcação. É uma vantagem muito valiosa. Talvez não apenas para mim, mas para todos os futuros usuários que poderão compartilhar seus desenvolvimentos ou simplesmente copiar partes de seus desenvolvimentos anteriores. É algo indispensável.

Ou seja, é absolutamente impossível abrir mão de uma linguagem de marcação por causa de um editor visual. Eu não entendia isso antes....

Portanto, hoje o problema é desenvolver um sistema de combinação harmoniosa de recursos de linguagem e editor visual. E, na verdade, tecnicamente, isso é muito fácil de fazer. (1) Em primeiro lugar, todas as funções necessárias do editor visual foram escritas e testadas há vários anos, (2) e, em segundo lugar, os principais mecanismos da linguagem de marcação foram bem reforçados nos últimos meses e uma grande atualização foi realizada com a adição do gerenciamento de interface de software. Em outras palavras, tudo está pronto para a integração e a fusão, e a tarefa é apenas pensar no conceito de interação sem conflitos de ambas as funcionalidades no processo de modelagem e criação de uma interface gráfica.

Conceitualmente, a linguagem de marcação e o editor visual REALMENTE entram em conflito.

Há vários motivos que dificultam essa tarefa:

Lembre-se de que os elementos e as janelas da GUI são escritos em código como padrão, mas também podem ser criados em um editor visual, conforme mostrado no gif acima.

1) Tanto no primeiro quanto no segundo caso, a funcionalidade do construtor constrói o núcleo gráfico, embora de maneiras diferentes, mas como os recursos do editor visual são mais fracos do que os da linguagem, os elementos criados não aceitam um conjunto completo de configurações do usuário por meio do editor. As configurações podem ser complementadas com a criação de um editor, mas, nesse caso, a linguagem de marcação se torna desnecessária, e isso é ruim, pois não há possibilidade de confiar em modelos de código. Não se pode abrir mão da linguagem de marcação, ponto final.

2) Ao criar novos elementos e janelas no modo visual, a linguagem de marcação não os "vê". Ou seja, a linguagem de marcação não é atualizada durante a construção visual da GUI. Nada é "adicionado" ao código kib original. Esse fato leva novamente à separação conceitual entre o editor visual e a linguagem de marcação. É um conflito.

Então, como ser e o que fazer nessa situação? Qual é o compromisso que leva à simbiose de duas poderosas ferramentas de criação de GUI?

Tentarei entender a solução:

Ponto principal: limitar a função do editor visual na modelagem da interface, deixando os recursos da linguagem inalterados. Na prática, isso significa:

1. Recusar-se a criar novos elementos e janelas no modo visual, pois o código de marcação não é atualizado ao adicioná-los.

2. Deixe a possibilidade de editar posições e definir propriedades de elementos e janelas da GUI do usuário por meio das janelas de configurações do editor visual, além dos valores padrão e personalizados do usuário no código kib. Nesse caso, o editor escreverá e salvará um arquivo especial com substituições de valores, a partir do qual ele os carregará no kernel e os atribuirá aos elementos. De fato, isso significa um novo tipo de modelos de elementos "processados" no editor. Eles não entrarão em conflito com os modelos de código kib, apenas substituirão os valores de propriedade definidos neles.

Na minha opinião, essa é uma simbiose eficaz entre o editor e a linguagem de marcação.

P.S. A ironia é que, tecnicamente, é possível concretizar a ideia de mesclar recursos de editor e linguagem em poucos dias, e isso é bastante realista, mas pensar em todos os detalhes de sua integração e interação no trabalho do usuário.... isso leva mais tempo. :)

P.S. Mas a principal conclusão é que eles PODEM e devem trabalhar juntos, complementando-se mutuamente.
 
O que você deseja fazer levará muito tempo, e seu código-fonte quase ninguém poderá contribuir para o desenvolvimento, você terá que confiar em si mesmo.
 
hini #:
O que você deseja fazer levará muito tempo, e seu código-fonte não poderá ser desenvolvido por ninguém. quase ninguém poderá contribuir, você terá que confiar em si mesmo.
Discordo totalmente da primeira afirmação. O conceito de um editor visual não foi apenas pensado há 4 anos, mas está tecnicamente implementado o suficiente para permitir que o usuário monte facilmente uma janela de configurações simples a partir de controles básicos. No designer, por exemplo, há uma marcação informativa com dimensões e grade, há um painel para definir propriedades e funções para salvar um projeto e imprimir um arquivo API, as mesmas janelas auxiliares com quadros, imagens e fontes. Tudo é como em uma linguagem de marcação.

Entretanto, para completar o editor visual, é necessário um navegador de arquivos. Ele fornecerá a capacidade de selecionar pastas para carregar ou salvar projetos, e a boa notícia é que o navegador de arquivos já existe - mostrei-o anteriormente nas páginas de ramificação - e, embora precise de ajustes, a funcionalidade básica funciona.

Além do navegador de arquivos, precisamos desenvolver o conceito de modelos semelhantes ao código kib. No início, achei que era impossível, mas a solução acabou sendo extremamente simples: se houver um navegador de arquivos, o editor visual poderá salvar a interface criada não como um projeto, mas como um modelo. Afinal de contas, em essência, é a mesma coisa. Além disso, não apenas o projeto inteiro, mas também janelas separadas desse projeto serão salvas como um modelo. Isso é fácil de fazer, porque apenas uma parte do núcleo construído é salva e pode ser carregada em outro projeto, e o usuário poderá extrair (por meio de cópia mostrada no gif acima) os elementos necessários e, em seguida, apagar esse modelo de seu projeto. Eu tenho a função de apagar janelas e elementos. É isso aí.

As tabelas podem ser criadas simplesmente copiando células de acordo com o exemplo dos botões no gif acima. É a mesma coisa. Uma lista em árvore é mais complicada.... mas não é o principal.

Com muito entusiasmo, tudo pode ser feito em um mês, um mês e meio. Mas agora estou ocupado preparando material para artigos, portanto, esse trabalho foi adiado.

Quanto à afirmação de que outros programadores não poderão desenvolver o projeto..... sim, eles não poderão desenvolver o projeto diretamente. Mas podem oferecer soluções, compartilhar sua experiência, opiniões, oferecer funções de trabalho com cores, com gradiente. Estou aberto a essa interação e cooperação.
 
Реter Konow #:

...

Entretanto: um navegador de arquivos é absolutamente necessário para completar o editor visual. Ele fornecerá a capacidade de selecionar pastas para carregar ou salvar projetos, e a boa notícia é que o navegador de arquivos já existe - mostrei-o anteriormente nas páginas de ramificação - e, embora precise de ajustes, a funcionalidade básica funciona.
...


Para não ser infundado, eis como o navegador de arquivos funciona (esquerda). Você só precisa integrá-lo ao editor.

 

Este vídeo mostra a criação da janela de configurações no editor visual do MT5. Por meio dele, você pode avaliar aproximadamente o grau de conclusão do editor.


 
hini #:
O que você deseja fazer levará muito tempo, e seu código-fonte não será mais o mesmo. quase ninguém poderá contribuir para o desenvolvimento, você terá que confiar em si mesmo.
Gostaria de saber com que propósito você escreveu essa postagem. :) Só estou pensando.

Talvez, como muitos outros, você esteja tentando me fazer perceber a futilidade dos esforços e aspirações..... para me levar a perceber a inatingibilidade de minhas metas... talvez esteja tentando me mostrar que conhece outro caminho. ou sabe Deus o que mais.

Mas vou ser sincero - não importa. Escreverei os artigos e terminarei o editor visual como pretendia. E que ele continue sendo um "cavalo esférico no vácuo" inútil para todos. Que assim seja.

Para mim, é um estágio importante de desenvolvimento.

Enfatizo: para mim, é um estágio essencial de desenvolvimento.

Portanto, o editor "simplesmente será". Independentemente do meu raciocínio, do seu raciocínio ou do raciocínio de qualquer outra pessoa, argumentos, contra-argumentos, raciocínios, avaliações, humores, suspiros, balanços de cabeça etc.

O editor visual está APENAS SENDO (concluído).

"Por que", "para que", "como" e "por que" aplicá-lo... ou não.... deixe que cada um decida por si mesmo... POR ELE MESMO.

Paz. :)
 
Реter Konow #:
Gostaria de saber com que propósito você escreveu essa postagem. :) Só para saber.

Talvez, como muitos outros, você esteja tentando me transmitir uma mensagem sobre a futilidade do esforço e da luta.... para me levar a perceber a inatingibilidade de meus objetivos... talvez esteja tentando me mostrar que conhece outro caminho. ou Deus sabe o que mais.

Mas, sinceramente, isso não importa. Escreverei artigos e terminarei o editor visual como pretendia. E que ele continue sendo um "cavalo esférico no vácuo" inútil para todos. Que assim seja.

Para mim, é um importante estágio de desenvolvimento.

Enfatizo: para mim, é um estágio essencial de desenvolvimento.

Portanto, o editor "simplesmente será". Independentemente do meu, do seu, ou de qualquer outra pessoa, raciocínio, pensamento, argumentos, contra-argumentos, raciocínio, avaliações, humores, suspiros, balançar de cabeça, etc.

O editor visual é APENAS BOM (acabado).

"Por que", "para que", "como" e "por que" aplicá-lo... ou não aplicá-lo..... deixe que cada um decida por si mesmo... POR ELE MESMO.

Paz. :)

Não quero dizer mais nada, é apenas uma ideia; eu o apoio na concretização do que você deseja fazer.

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



<editado pelo moderador> em russo: Não quero dizer mais nada, é apenas uma ideia; eu o apoio na realização do que você deseja fazer.

 

Peter, acho que o que você está fazendo é fantástico! Saiba que você tem meu incentivo em seu esforço.
É muito fácil para as pessoas dizerem "nunca deixe que a perfeição seja inimiga do bom", mas é mais fácil falar do que fazer quando você
tem uma visão de como seu projeto deve funcionar.
Aguardo ansiosamente os próximos artigos etc... sobre como seu editor visual funcionará.
E saiba que um bom editor visual nunca será um "cavalo esférico inútil no vácuo".

Saudações

Doug

 
hini #:

Não quero dizer mais nada, é apenas uma ideia; eu o apoio na concretização do que você quer fazer.

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



<editado pelo moderador> em russo: Não quero dizer mais nada, é apenas uma ideia; eu o apoio na realização do que você quer fazer.

Obrigado por seu apoio e participação contínuos, que me ajudaram muito na condução deste tópico.
 
Douglas Prager projeto deve funcionar.
Estou ansioso para ler mais artigos, etc. .... sobre como seu editor visual funcionará.
E saiba que um bom editor visual nunca será um "cavalo esférico inútil em um vácuo".

Com os melhores cumprimentos,

Doug

Muito obrigado, Douglas, por suas palavras inspiradoras. Sei que quando as pessoas se livram das camadas de críticas derrotistas, desvalorizando aspirações e ideias degradantes com convicção, elas alcançam os picos mais altos juntas!
1...656667686970717273747576777879...82
Novo comentário