Fazendo um projeto de crowdsourced em Tela - página 13

Novo comentário
 
Igor Volodin:


Para mim, é mais fácil criar uma equipe de desenvolvimento de produto, cujos membros, em um grau acordado, receberão um lucro com a venda do produto (talvez alguém seja o ideólogo do projeto, alguém financia por uma ação, alguém é o programador).

E como todos estão motivados financeiramente, implementar as bibliotecas necessárias para a interface também como parte do projeto.

concordado, mas a biblioteca em si deve ser aberta a multidões )
 
o_O:
Igor Volodin:


Para mim, é mais fácil criar uma equipe de desenvolvimento de produto, cujos membros, até certo ponto, receberão um lucro com a venda do produto (talvez alguém seja o ideólogo do projeto, alguém financia por uma ação, alguém é o programador).

E como todos estão motivados financeiramente - para implementar dentro do projeto e as bibliotecas necessárias para a interface.

Concordo, mas a biblioteca em si deveria ser de código aberto (crowdsourced).
Eu li o fio e não entendi o que é necessário - desenhar o botão em Tela do zero. Você pode explicar sem emoções?
 
Alexey Volchanskiy:
Eu li o fio e ainda não entendo por que é necessário desenhar um botão na Tela do zero. Você pode explicar sem emoções?
Eu escolho entre ObjectCreate e ResourceCreate.
porque os desenvolvedores de MT não são onipotentes e é demorado aborrecê-los com pedidos mesquinhos
 

Por que isso pode vir a ser útil:

1. A interface no bitmap é rápida. Tão rápido que é quase indistinguível do sistema. Por exemplo, implementei elementos semi-transparentes com gradientes emesmo quando eles se movem são suavemente renderizados sem atrasos visíveis, levando em conta a mistura de cores e o cálculo do canal alfa em outros objetos com gradientes semi-transparentes.

2. A interface é escalável. Você pode tornar a aplicação mais complexa e não vai diminuir a velocidade devido à eliminação e criação de um grande número de objetos gráficos. Os custos de redesenho são mínimos, apenas um milésimo de segundo.

3. Controles prontos podem ser criados e novos controles podem ser criados, pois você pode fornecer seu próprio pool de eventos, por exemplo:

OnMouseDown - pressionado o LKM

OnMouseUp - pressionou o LKM

OnMouseHoverOn - passe o cursor do mouse sobre um objeto

OnMouseHoverOut - mover o cursor do mouse para longe do objeto

OnMouseClick - pressione e clique dentro dos limites do objeto

OnMouseDblClick - clique duplo do mouse dentro dos limites do objeto

OnDragStart - evento que ocorre uma vez no início do movimento com o botão esquerdo do mouse pressionado

OnDragMove - evento gerado durante o movimento com o botão esquerdo do mouse

OnDragEnd - evento gerado após mudança com LKM

OnPut - objeto é lançado para outro objeto

OnGet - objeto é jogado em outro objeto

OnFocus - objeto tem foco

OnBlur - objeto perde o foco

OnResize - o objeto mudou de tamanho

OnParentResize - o objeto pai mudou de tamanho

OnKeyPress - tecla pressionada

OnChange - valor de um campo alterado

etc.

 
Igor Volodin:

Por que isso pode vir a ser útil:

1. A interface no bitmap é rápida. Tão rápido que é praticamente indistinguível da interface do sistema. Por exemplo, implementei elementos semi-transparentes com gradientes e,mesmo quando se movem, são suavemente renderizados sem qualquer atraso visível, levando em conta a mistura de cores e o cálculo do canal alfa em outros objetos com gradientes semi-transparentes.

2. A interface é escalável. Você pode tornar a aplicação mais complexa e não vai diminuir a velocidade devido à eliminação e criação de um grande número de objetos gráficos. Os custos de redesenho são mínimos, é apenas a substituição de um quadro em um milésimo de segundo.

3. Controles prontos podem ser criados e novos controles podem ser criados, pois você pode fornecer seu próprio pool de eventos, por exemplo:

OnMouseDown - pressionado o LKM

OnMouseUp - pressionou o LKM

OnMouseHoverOn - passe o cursor do mouse sobre um objeto

OnMouseHoverOut - mover o cursor do mouse para longe do objeto

OnMouseClick - pressione e clique dentro dos limites do objeto

OnMouseDblClick - clique duplo do mouse dentro dos limites do objeto

OnDragStart - evento que ocorre uma vez no início do movimento com o botão esquerdo do mouse pressionado

OnDragMove - evento gerado durante o movimento com o botão esquerdo do mouse

OnDragEnd - evento gerado após mudança com LKM

OnPut - objeto é lançado para outro objeto

OnGet - objeto é jogado em outro objeto

OnFocus - objeto tem foco

OnBlur - objeto perde o foco

OnResize - o objeto mudou de tamanho

OnParentResize - o objeto pai mudou de tamanho

OnKeyPress - uma tecla pressionada

OnChange - valor de um campo alterado

etc.

Exaustivo, obrigado!

 
Leia o fio, interessante. É uma pena que não houvesse tanta agitação em relação às interfaces há cerca de 3 anos.

Não vejo nenhum sentido em colocar meu código, pois há uma alta probabilidade de que a iniciativa se extinga devido à preguiça e às dificuldades de comunicação entre os participantes (e eles já são observados) meu código será arrastado para o porão para ser modificado por mim mesmo e eu (e a comunidade) não me beneficiarei em nada com isso.

Mas para participar do projeto eu poderia, a partir da discussão das características necessárias e dos detalhes específicos de implementação, uma vez que há um benefício em tal, vamos chamá-lo de uma estrutura.

O benefício é simples, expressado por Alex nos primeiros posts. A comunidade pode influenciar os desenvolvedores do terminal a introduzir modificações na plataforma MQL.

Minhas esperanças de melhorias (diretamente relacionadas com as interfaces de programação) são as seguintes:

  1. Aplicação MQL - como um tipo separado de programa que não cancela outros (não tem onTick e nenhuma possibilidade de se referir ao símbolo padrão - é uma relíquia do passado, mas tem a possibilidade de obter o ambiente comercial de qualquer símbolo e comércio, porque tudo é multimoeda), a aplicação não deve começar no gráfico de um símbolo em particular, mas em sua própria janela. Se você arrastar tal programa para uma tabela, uma nova janela se abrirá. E arrastar e soltar não é necessário - 2 cliques no navegador - também abre uma nova janela. Isto é similar ao pedido de algumas pessoas de fornecer API ao terminal para desenvolvimento em outro idioma. Tema de desenvolvimento - pode ser assumido que tal programa, especialmente compilado, pode ser executado sem um terminal (e por razões de segurança, permitir esta compilação somente através do Mercado). Pode parecer selvagem, mas e se?
  2. Suporte para fontes vetoriais de terceiros apresentadas como um arquivo separado e a capacidade de compilação como um recurso (declarada na documentação, mas não implementada)
  3. Captura de eventos com o mouse
  4. Bloqueio do menu com o botão direito do mouse. O botão certo é agora manejado, mas é inútil.
  5. O manuseio da prancheta do sistema, para criar seus próprios controles de edição de texto (incluindo editor de várias linhas), barra de espaço e entrada já pode ser bloqueado - bom.
 

@Igor Volodin, @Combinator, @Anatoli Kazharski

Vou começar com o assunto doloroso).
A questão que mais me preocupa é algum tipo de universalidade/abstração para armazenar parâmetros de renderização.

----

Como entendemos que todos os controles utilizam a fonte, a cor do fundo e a cor do texto igualmente, etc.
Quando todos estes parâmetros são os mesmos para todos os controles, então a interface tem uma aparência comum com um único conceito.

Mas como armazená-las? porque os controles nem sempre utilizam todos os parâmetros.
+ O sistema é complicado pelo fato de que os elementos têm estados diferentes que devem usar fontes e cores de fundo diferentes. Eles são Ativos, Desativados, Desativados, Over, ou Selecionados, etc.
+ há grupos de controladores - alívio (como Botão) e campos de entrada (como Editar, Listar), e quando é o fundo para torná-los

----

Na idéia de trabalho atual eu tenho um elemento de atributo mínimo da classe GAttribBase, que contém 5 parâmetros básicos (fonte/tamanho, cor do fundo/borda, tamanho da borda)

Estes elementos básicos são usados para formar uma matriz para os estados da classe GAttribut(Ativo/Disabvle/Over/Select, etc.).

E então o GAttribut é preenchido para os diferentes tipos de elementos - Alívio, Editable, etc.


Assim, preenchemos uma vez os parâmetros de renderização (os armazenamos em xml), eles podem ser editados para criar diferentes designs e os usamos globalmente sem defini-los para cada controlador.

É claro, se algum controlador precisa ter seus próprios parâmetros de renderização definidos - basta criar seu próprio objeto GAttribut no controle e especificar as cores desejadas.

----

Este modelo funciona, o projeto unificado é alcançado em pouco tempo, todos os controles tiram as cores da matriz comum.

Mas, na minha opinião, não é universal. O usuário não entende quais parâmetros da base GAttribBase são usados para a renderização deste ou daquele controle.
Para que o codificador saiba exatamente qual a cor a ser mudada, ele teria que procurar a função de renderização do controle, o que é realmente incômodo.

-----

De qualquer forma, quaisquer idéias para que o codificador fique livre do gerenciamento de cores (para usar cores predefinidas imediatamente e não se incomodar com elas no início).

Por outro lado, se ele quiser colorir novamente alguns dos controles na tela, ele não precisa investigar o que GAttribBase é usado e em que caso.

 
o_O:

@Igor Volodin, @Combinator, @Anatoli Kazharski

Em geral - que idéias você tem para que o codificador esteja livre do trabalho de cores por um lado (para que ele use as cores dispostas imediatamente e não se preocupe com elas no início)

E por outro lado, se quiserem colorir novamente alguns dos controles na tela, podem fazê-lo sem entrar no labirinto de funções de desenho e procurar o que GAttribBase é usado e em que caso.

Ok, temas.

Por exemplo, o objeto principal de nossa aplicação, vamos chamá-lo App, está associado ao objeto ConcreteTheme.

O que é um objeto temático:
cores (fundo, primeiro plano, desabilitar, ativo, etc.), tamanhos de base, tamanhos de fonte para caixas padrão: tamanho de títulos, tamanho comum, etc. sprites para: painéis, botões, caixas de seleção, etc.

Um novo tema é uma nova classe/estrutura com valores alterados. Mas é melhor que os temas possam ser herdados prevalecendo apenas certos parâmetros.


O resto - a hierarquia de controles na qual cada controlador utiliza um dos valores necessários do objeto-tema por padrão. Se for necessário anular isto, chamamos um método para trabalhar com aquele imóvel, especificando o novo valor.

Por exemplo, SetBgColor(XRGB(255,0,128));

CView - uma classe básica que proporciona interação básica baseada em eventos
- CRect - coordenadas
- Cpanel tem um bgcolor
- O CButton tem um objeto de estado, cada estado tem bg
- CText tem uma cor de texto e propriedades da fonte
- CCircle

E assim por diante.

Se você quiser usar xml para descrever os elementos,

então para cada controle de classe ou primitivo precisamos criar uma classe geradora, vamos chamá-la de "build-container" que irá mapear atributos (bgcolor="(255,0,128)") para os métodos correspondentes ( SetBgColor(attrValue) ) da classe. Tais recipientes construídos serão analisados pelo analisador XML, a saída será um objeto inicializado com valores necessários, ou com valores padrão se nenhum valor for especificado.

 

Aqui o Tema é o mesmo que o meu - um conjunto de GAttributors para diferentes tipos de controles e seus estados.

mas você já sugere o primeiro passo no caminho da transparência para o codificador - adicionar funções ao controle específico para alterar suas propriedades de renderização (SetBgColor etc.)

Basicamente, concordo que ficará claro que cores tem e o que pode ser mudado.


tal pergunta então - o tema implica redundância de parâmetros não utilizados?

Digamos que em meu GAttribBase básico para algum controle (por exemplo, botão) usamos apenas a cor e o tamanho do fundo, e outros parâmetros - espessura da borda, etc. - não são usados neste controle.

Isto é - você tem um elemento básico para todos os controles? onde são armazenadas as informações "para todos os casos", ou todos os controles têm apenas seus parâmetros sem a sobrecarga da universalidade?

 
o_O:

...

Em geral - quais são algumas idéias para que o codificador fique livre do manuseio de cores (para que use cores padrão e não se preocupe com elas no início)

E por outro lado - para que se ele quiser colorir novamente algum controlador na tela, ele não tenha que mergulhar no deserto das funções de renderização e descobrir o que GAttribBase é usado e em que caso.

Defina os valores padrão para cada item. Se o usuário precisar mudar alguma coisa, para cada item de propriedade deve haver um método para definir um novo valor. É assim que eu tenho feito agora.

Eu ainda não tenho isto:

Se você precisar alterar as propriedades de todos os elementos em "duas contagens", então basta criar métodos separados (para propriedades comuns relacionadas ao projeto e aplicáveis a todos os elementos) naquela classe onde todos os elementos de interface são acessíveis.

Em princípio, já posso ver como isto poderia ser implementado em meu esquema. Por exemplo, através de eventos. Mas então no manipulador de eventos de cada elemento precisamos lidar com este evento (o código está inchado). Segunda opção, criar um método público especial em uma classe que lida com eventos GUI comuns, ou até mesmo superiores, onde todas as indicações para elementos GUI são armazenadas. Ambos são classes de base de aplicação MQL personalizada, e o usuário terá acesso direto a eles. Pode ser algo como métodos ObjectSet sobrecarregados em MQL (por exemplo,ElementSet), onde (1) propriedade e valor ou (2) propriedade, modificador e valor devem ser especificados.

Mas tudo isso é o meu raciocínio em relação ao meu esquema. Não descarto que isso ainda mude muito quando eu iniciar a transição. Portanto, tudo o que escrevi acima pode não ser mais relevante para o tópico em discussão aqui. )

1...67891011121314151617181920...45
Novo comentário