Galería de interfaces de usuario escritas en MQL - página 74

Nuevo comentario
 
Periodo aproximado de publicación, del 22 al 28 de noviembre.

P.D. Por favor, tengan en cuenta la gran cantidad de trabajo. Gracias.
 
Реter Konow #:
Periodo de lanzamiento provisional, entre el 22 y el 28 de noviembre.

P.D. Por favor, tengan en cuenta la gran cantidad de trabajo. Gracias.

Me encantaría ser beta tester :)

 

... Hablando de contenido (para "futuras ideas") :

Actualmente estoy "probando suerte" diseñando un Panel directamente desde Objetos Terminales: Botón y Etiqueta de Texto,

y me encontré con esta situación : -->

--> para "mi mismo" - para evitar confusiones en los Botones - decidí firmar el propio botón "en detalle".
y en consecuencia - fue necesario hacer la inscripcion no en el boton mismo (ya que la inscripcion estara en el medio de la altura del boton), sino en forma de texto "superpuesto" en el boton (!) por eso la inscripcion resulto ser de 2 lineas:

de ahí la premisa de expresar esta situación - en caso de que en el futuro, se "invente" una manera - CÓMO hacer tales leyendas de 2-3 líneas en los botones en su GUI --> sin o con kanvas --

 
Vitaliy Kostrubko #:

Me encantaría ser un Beta tester :)

Gracias por la iniciativa.

Sin duda ayudará a mejorar la calidad de la aplicación técnica. Pero debo decir de una vez, el código del constructor o editor no es objeto de discusión. Sólo el trabajo de la funcionalidad y el cumplimiento de los requisitos del usuario. Este es un requisito previo. Si está de acuerdo, todo irá "sobre raíles". :)
 
Vitaliy Kostrubko #:

... CÓMO hacer subtítulos similares de 2-3 líneas en los botones de su GUI --> sin kanvas, o CON kanvas

Will.
 
Se ha tomado la decisión estratégica, cuidadosamente meditada, de centrarse por completo en restaurar la funcionalidad del editor visual. Según estimaciones aproximadas, podrá estar mínimamente completo y ser aplicable en la práctica en las próximas 3 semanas. A partir de entonces, sólo se procederá a su desarrollo y mejora.

Explicaré las razones de esta decisión más adelante.
 
Vitaliy Kostrubko #:

... Hablando de contenido (para "ideas para el futuro") :

Actualmente estoy "probando mi mano" en el diseño de un panel directamente a partir de objetos de Terminal: Botón y Etiqueta de texto,

y me encontré con esta situación : -->


--> Para "mí mismo" - para evitar confusiones en los botones - decidí firmar el botón "detalle" en sí.
y en consecuencia - era necesario hacer la inscripción no en el propio botón (ya que la inscripción aparecerá en el medio de la altura del botón), pero en forma de texto "superpuesto" en el botón (!) . Es por eso que la inscripción resultó ser de 2 líneas:

de ahí la premisa de expresar esta situación - en caso de que en el futuro, se "invente" una manera - CÓMO hacer tales leyendas de 2-3 líneas en los botones en su GUI --> sin o con kanvas --

¿correcto? :-)

sin editores GUI :-)

o así...

o así.

:-)

para que conste y me sobraran 10 minutos...

 
Por qué no tiene sentido seguir desarrollando la dirección del lenguaje de marcas:

1. Umbral de entrada elevado.

Para que los usuarios construyan paneles complejos necesitan conocer las reglas del lenguaje. Pero sólo las conocerán después de estudiar ~20 tutoriales que tengo que escribir en los próximos 6-7 meses.

2. Es imposible utilizar plenamente las plantillas GUI sin conocer las reglas del lenguaje.

El conocimiento se obtiene de tutoriales, y los materiales se imprimen en artículos. Los artículos se publican a intervalos de uno o dos al mes. Para completar un curso completo de estudio es necesario publicar al menos 7 - 10 artículos, y a este ritmo el proceso durará ~ medio año.

La conclusión de los argumentos anteriores es que tiene sentido publicar plantillas sólo después de publicar los artículos. Sin conocimientos prácticos del lenguaje, los usuarios no podrán modificar las plantillas de código kib para adaptarlas a sus necesidades, lo que reducirá significativamente su utilidad. En consecuencia, los usuarios acudirán a mí en busca de explicaciones y ayuda. Puedo ayudar a una o dos personas, pero si hay más, estaremos en un callejón sin salida.




Ahora, por qué tiene mucho sentido desarrollar un editor visual.

1. Bajo umbral de entrada para los usuarios.

El editor visual tiene la ventaja de ser intuitivo. Sus capacidades y limitaciones se reconocen fácilmente explorando su interfaz gráfica. Añadir tooltips ayuda a comprender las complejidades.

2. La cantidad de material de formación necesario para iniciarse en el editor visual es reducida.

Todo el curso se puede resumir en 3 - 5 artículos. Pero incluso sin ellos los usuarios aprenderán rápidamente a crear paneles simples y complejos.

3. El editor simplifica y acelera al máximo la creación de GUI.

La diferencia entre el esfuerzo de trabajar con un lenguaje de marcado y un editor visual es enorme. Este factor inclinó finalmente la balanza a favor del editor visual. El escaso esfuerzo requerido influye favorablemente en el interés de los usuarios por crear aplicaciones comerciales GUI.

4. La base conceptual del editor visual está bien pensada, y la base técnica fue escrita y probada hace 4 años. Podemos decir que, objetivamente, el editor se encuentra en el umbral de su primera versión.
 
Maxim Kuznetsov #:

¿verdad? :-)

esto es sin editores GUI :-)

o así.

o esto

:-)

Sólo digo, y me sobraban 10 minutos...

Por supuesto, habrá gente que quiera usar programas de terceros para construir GUI y conectarlo vía DLLs, está bien.

Es elección de cada uno.
 
Реter Konow #:
...
4. La base conceptual del vis.editor está bien pensada, y la base técnica fue escrita y probada hace 4 años. Podemos decir que el editor está en el umbral de su primera versión.
Merece la pena explicar este punto en detalle.

El Editor Visual (VE) requiere la funcionalidad mínima necesaria para ser implementado. Vamos a considerar en general lo que es.

Base funcional del VE:

1. Interacciones de edición y elementos editables.

2. Separación del núcleo gráfico en una zona de personal y otra de usuario. Los elementos editables y de edición deben estar en partes diferentes del núcleo, los primeros en el área de personal, los segundos en el área de usuario.

3. Las funciones de creación y eliminación de elementos y ventanas deberían trabajar con la parte de usuario del núcleo, y ser llamadas por elementos de la estándar.

4. Funcionalidad de guardar la parte personalizada del núcleo tras la edición de la GUI.

5. 5. Cargar la parte guardada del kernel (proyecto) desde un archivo, para rediseñar y refinar el proyecto.


Esto es lo mínimo necesario para un editor que funcione.


Lo que ya está implementado:

1. Interacción de editores y elementos editables.

Los editores tienen dos propiedades específicas: Target_object y Target_property. Cuando el usuario pulsa sobre un elemento editable, éste pasa a tener un foco especial. En ese momento, los elementos editores toman los valores de propiedad del elemento editable en sus parámetros de acuerdo con su propiedad Target_property y los emiten a través de su otra propiedad especial, Output_property. Es decir, si Target_property es el color del elemento, entonces Output_property puede ser o bien un texto que muestre el nombre del color del elemento editable, o bien el color base del elemento editor, que cambia en consecuencia.

Hay muchas variantes de interconexión de estos elementos, pero la implementación técnica no es una tarea difícil y es bastante simple.

2- El constructor tiene ahora su propio archivo API interno, lo que facilita el uso de la funcionalidad de sus propias ventanas de personalización utilizando funciones envoltorio y eventos GUI entrantes.

3- Además, el constructor se puede cargar de dos formas - desde el kernel directamente, saltándose el proceso de interpretación del código kib, o de forma estándar, a través de la interpretación del código kib. Gracias a esto, el tiempo de carga del constructor en el gráfico se ha reducido de ~1,5 segundos a ~16 - 32 milisegundos. Además, gracias a la carga desde el archivo kernel hemos conseguido librarnos de las advertencias relacionadas con kib-code. Pero quizás esto no sea más que una nimiedad comparado con las perspectivas. La principal ventaja de cargar desde un kernel listo es la posibilidad de "completar" partes del kernel listas desde otros archivos, que pueden ser plantillas de ventanas o grupos de elementos necesarios para el trabajo del usuario. Esto está a un paso.

4. Las carpetas y archivos del constructor están completamente traducidos al inglés. La arquitectura ha sufrido grandes cambios.

Mi objetivo principal es crear la funcionalidad mínima del editor que le permite construir el editor de adentro hacia afuera, pasando por alto el lenguaje de marcado.

1...676869707172737475767778798081...83
Nuevo comentario