Galeria de UIs escritas em MQL - página 72

[Реter Konow]

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.

[hini]

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.