GUI de origem popular. Testes beta abertos. - página 8
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
que tudo isso vai para o estilo habitual. Há certos momentos, como o botão de ligação, o botão de pairar, o botão de clicar e apenas o botão. E para cada momento eles geralmente fazem seus próprios estilos, ou uma mistura deles.
Para dizer a verdade, eu sempre entendi mal em tais coisas como organizar as configurações do código executado para um botão. Para que fosse também visual. E também com suas próprias verificações do código para erros.
Um exemplo vivo de tal trabalho seria a criação de um menu para criar um menu. Ou seja, se graficamente for possível fazer o menu esquerdo ou direito com código embutido, por assim dizer, na hora certa.
Ou é apenas a geração de botões em code....?
A criação dos estilos é apenas o início da edição. A seguir, o número de características crescerá de forma avalanche. A tarefa principal é arrastar e soltar as características básicas da linguagem de marcação para o editor visual. Não é difícil de fazer. Eu diria que há uma espécie de avanço no nível visual, como romper uma barreira supersônica. É difícil de descrever... - é como se as possibilidades estivessem trancadas sob uma fechadura e agora, quando você vai ao visual, a porta para eles se abre e eles se amontoam. Apenas tempo para implementar.
Próximas tarefas:
1. Adicionando janelas.
2. Remoção de elementos.
3. Criando uma nova ferramenta - moldura azul.
4. Cópia de elementos dentro da janela.
5. Ampliando o foco de edição.
6. Adicionando metas de edição.
7. Seleção e carregamento de projetos salvos.
8. Atualização do motor.
...
//------------------------------------------------
O código não é essencialmente gerado. É gerado um kernel contendo os elementos da descrição numérica. Ela é lida pelo motor anexado à aplicação do usuário e gerencia a comunicação bidirecional.
A criação de estilos é apenas o início da edição. A seguir, o número de características crescerá como uma avalanche. A tarefa principal é arrastar e soltar as características básicas da linguagem de marcação para o editor visual. Não é difícil de fazer. Eu diria que há uma espécie de avanço no nível visual, como romper uma barreira supersônica. É difícil de descrever... - é como se as possibilidades estivessem trancadas sob uma fechadura e agora, quando você vai ao visual, a porta para eles se abre e eles se amontoam. Apenas tempo para implementar.
Próximas tarefas:
1. Adicionando janelas.
...
//------------------------------------------------
O código não é essencialmente gerado. O que é gerado é um kernel contendo os elementos da descrição numérica. É lido por um motor acoplado à aplicação do usuário e gerencia a comunicação bidirecional.
O que eu gostaria: criar um estilo base e editá-lo, criando estilos padrão. Personalizando o estilo de botão separadamente. Deve ser dada maior ênfase aos modelos de estilo, tirando algo da tendência moderna.
Possibilidade de pelo menos alguma edição do código dos arquivos do usuário em tempo real. Por exemplo, a convocação de certas classes ou a lista a ser mostrada. Por conseguinte, deve ser o padrão de uma certa resposta para o pós-processamento posterior.
É lógico que haja uma possibilidade de edição visual - mas é apenas o primeiro passo, no qual eu acho lógico usar o botão direito e fazer ali um menu definido. Em geral, é mais fácil tornar o código independente - porque no futuro você pode precisar dele não apenas para o trabalho em MT. Os arquivos são plugáveis de acordo. Pelo menos nos nichos, se o fizermos para o mercado.
Normalmente em tais direções cada novo passo leva a ainda mais problemas no código, muitas vezes parece que tudo pode ser feito em um certo período de tempo, mas na verdade leva muito mais tempo. E este será sempre o caso, a avalanche só aumentará figurativamente a funcionalidade após o lançamento da primeira versão totalmente funcional.
O que seria desejável: criar um estilo base e editá-lo, criando estilos padrão. Personalize o estilo do botão separadamente. Deve ser dada maior ênfase aos modelos de estilo, tirando algo da tendência moderna.
Possibilidade de pelo menos alguma edição do código dos arquivos do usuário em tempo real. Por exemplo, uma chamada para certas classes ou uma lista, que precisa ser mostrada. Portanto, deve haver uma resposta padrão para o pós-processamento posterior.
É lógico que deve haver uma ampla possibilidade de edição visual - mas é apenas o primeiro passo, onde eu acho lógico usar o botão direito e fazer ali um menu definido. Em geral, é mais fácil tornar o código independente - porque no futuro você pode precisar dele não apenas para o trabalho em MT. Assim, os arquivos são plugáveis. bem, pelo menos nos nódulos se o fizermos para o mercado
Vou pensar em salvar os modelos de estilo. Em uma linguagem de marcação, isto foi fácil. Ali, a cadeia de propriedade poderia ser simplesmente copiada de elemento a elemento e pareceria correta. Aqui não temos uma corrente direta, mas qual é o problema de fazer uma? Acho que poderia ser melhor e mais simples. Algo como um conjunto de estilos com valores salvos de propriedades dos modelos.
Sobre a possibilidade de editar arquivos utilizáveis - não entendemos exatamente do que estamos falando. Um exemplo seria...
Os arquivos necessários para a conexão são impressos. Há dois deles. Eles contêm as informações de carga para o motor e a api para a aplicação do usuário. Para que ela "se comunique" com os elementos.
Imprimir texto sobre os elementos.
pense na grade - é necessário algum tipo de alinhamento/alinhamento. já é difícil alinhar uniformemente três elementos
Eu concordo. Vou pensar sobre isso.
pensar sobre a grade - é necessário algum tipo de alinhamento/limitação.
Sim, toda esta grade é 10 vezes para .......
Necessidade de ver o interesse do usuário. Por exemplo, se fosse possível criar este ou aquele gráfico na mosca... por exemplo, traçar uma linha por máximos e assim por diante.
Porque até agora nada mais é do que uma lição muito boa para o autor na concepção do programa. Criar apenas um menu não é tão interessante assim. E as chamadas de função devem vir de um botão.
Embora, devido à popularização da tela em html, haja um interesse esportivo em implementar algo universal. Mas é muito complicado para mim
....
É certo que existe outra opção - limitar-se à geração de códigos. Como um "inludnik" com todo o layout dos botões é criado e tudo o que resta é inserir os dados ....... - também uma variante. PS: A opção mais próxima e mais viável
Meu objetivo é implementar a seguinte lista de tarefas até o dia 3 de março:
1. Adicionar/remover janelas.
2. Eliminação de itens.
3. Criando uma nova ferramenta - moldura azul.
4. Cópia de elementos dentro da janela.
5. Ampliando o foco de edição.
6. Adicionando metas de edição.
7. Seleção e carregamento de projetos salvos.
8. Atualização do motor.
9. Posições dos elementos na grelha e autocorreção.
//------------------------------------------------
Depois disso, o editor visual pode ser usado para criar uma interface semelhante à do Windows para aplicações personalizadas.
(sic. com um conjunto de elementos simples. Isto será seguido por tabelas e várias listas).
Peter inventou e escreveu o Windows! Apenas 30 anos tarde demais =)
Seguindo as pegadas dos gigantes).