Realización de un proyecto crowdsourced en Canvas - página 13
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Para mí, es más fácil crear un equipo de desarrollo de productos, cuyos miembros, en un grado acordado, recibirán un beneficio de las ventas del producto (quizá alguien sea el ideólogo del proyecto, alguien financie una parte, alguien sea el programador).
Y ya que todo el mundo está motivado económicamente, para implementar las bibliotecas necesarias para la interfaz como parte del proyecto también.
Para mí, es más fácil crear un equipo de desarrollo de productos, cuyos miembros, en un grado acordado, recibirán un beneficio de las ventas del producto (quizá alguien sea el ideólogo del proyecto, alguien financie una parte, alguien sea el programador).
Y como todos están motivados económicamente - para implementar dentro del proyecto y las bibliotecas necesarias para la interfaz.
He leído el hilo y sigo sin entender por qué es necesario dibujar un botón en Canvas desde cero. ¿Puede explicarse sin emociones?
porque los desarrolladores de MT no son omnipotentes y es mucho tiempo molestarlos con peticiones insignificantes
Por qué puede ser útil:
1. la interfaz del mapa de bits es rápida. Tan rápido que es casi indistinguible del del sistema. Por ejemplo, he implementado elementos semitransparentes con gradientes eincluso cuando se mueven se renderizan suavemente sin retraso visible, teniendo en cuenta la mezcla de colores y el cálculo del canal alfa en otros objetos con gradientes semitransparentes.
2. la interfaz es escalable. Puedes hacer la aplicación más compleja y no se ralentizará debido a la eliminación y creación de un gran número de objetos gráficos. Los costes de redibujado son mínimos, sólo se trata de sustituir una imagen en una milésima de segundo.
3. se pueden crear controles ya hechos y otros nuevos, ya que se puede proporcionar su propio grupo de eventos, por ejemplo:
OnMouseDown - pulsó el LKM
OnMouseUp - pulsar el LKM
OnMouseHoverOn - pasar el cursor del ratón por encima de un objeto
OnMouseHoverOut - alejar el cursor del ratón del objeto
OnMouseClick - pulsar y hacer clic dentro de los límites del objeto
OnMouseDblClick - doble clic del ratón dentro de los límites del objeto
OnDragStart - evento que ocurre una vez al inicio del movimiento con el botón izquierdo del ratón pulsado
OnDragMove - evento generado durante el movimiento con el botón izquierdo del ratón
OnDragEnd - evento generado después de moverse con LKM
OnPut - el objeto se convierte en otro objeto
OnGet - el objeto es volcado a otro objeto
OnFocus - El objeto se ha enfocado
OnBlur - el objeto pierde el foco
OnResize - El objeto ha cambiado de tamaño
OnParentResize - El objeto padre ha cambiado de tamaño
OnKeyPress - una tecla pulsada
OnChange - El valor de un campo ha cambiado
etc.
Por qué puede ser útil:
1. la interfaz del mapa de bits es rápida. Tan rápido que es prácticamente indistinguible de la interfaz del sistema. Por ejemplo, he implementado elementos semitransparentes con gradientes eincluso cuando se mueven, se renderizan suavemente sin ningún retraso visible, teniendo en cuenta la mezcla de colores y el cálculo del canal alfa en otros objetos con gradientes semitransparentes.
2. la interfaz es escalable. Puedes hacer la aplicación más compleja y no se ralentizará debido a la eliminación y creación de un gran número de objetos gráficos. Los costes de redibujado son mínimos, sólo se trata de sustituir una imagen en una milésima de segundo.
3. se pueden crear controles ya hechos y otros nuevos, ya que se puede proporcionar su propio grupo de eventos, por ejemplo:
OnMouseDown - pulsó el LKM
OnMouseUp - pulsar el LKM
OnMouseHoverOn - pasar el cursor del ratón por encima de un objeto
OnMouseHoverOut - alejar el cursor del ratón del objeto
OnMouseClick - pulsar y hacer clic dentro de los límites del objeto
OnMouseDblClick - doble clic del ratón dentro de los límites del objeto
OnDragStart - evento que ocurre una vez al inicio del movimiento con el botón izquierdo del ratón pulsado
OnDragMove - evento generado durante el movimiento con el botón izquierdo del ratón
OnDragEnd - evento generado después de moverse con LKM
OnPut - el objeto se convierte en otro objeto
OnGet - el objeto es volcado a otro objeto
OnFocus - El objeto se ha enfocado
OnBlur - el objeto pierde el foco
OnResize - El objeto ha cambiado de tamaño
OnParentResize - El objeto padre ha cambiado de tamaño
OnKeyPress - una tecla pulsada
OnChange - El valor de un campo ha cambiado
etc.
Exhaustivo, ¡gracias!
@Igor Volodin, @Combinator, @Anatoli Kazharski
Empezaré con el tema del dolor).
El tema que más me preocupa es algún tipo de universalidad/abstracción para almacenar los parámetros de renderizado.
----
Según entendemos, todos los controles utilizan por igual la fuente, el color de fondo y el color del texto, etc.
Cuando todos estos parámetros son iguales para todos los controles, la interfaz tiene un aspecto común con un único concepto.
Pero, ¿cómo almacenarlos? porque los controles no siempre utilizan todos los parámetros.
+ El sistema se complica por el hecho de que los elementos tienen diferentes estados que deben utilizar los colores de la fuente y del fondo de manera diferente. Se trata de Activo, Desactivar, Sobre, o Seleccionar, etc.
+ hay grupos de controladores - relieve (como Button) y campos de entrada (como Edit, List), y cuando es el fondo para renderizarlos
----
En la idea actual de trabajo tengo un elemento de atributo mínimo de la clase GAttribBase, que contiene 5 parámetros básicos (fuente/tamaño, color de fondo/borde, tamaño del borde)
Estos elementos de base se utilizan para formar una matriz para los estados de la clase GAttributribut(Activo/Desactivado/Superado/Seleccionado, etc.).
Y luego se rellena GAttribut para los diferentes tipos de elementos - Relieve, Editable, etc.
Así, rellenamos los parámetros de renderizado una vez (los almacenamos en xml), se pueden editar para crear diferentes diseños y los usamos globalmente sin definirlos para cada controlador.
Por supuesto, si algún controlador necesita tener sus propios parámetros de renderizado definidos - simplemente cree su propio objeto GAttributribut en el control y especifique los colores deseados.
----
Este modelo funciona, el diseño unificado se consigue en poco tiempo, todos los mandos toman los colores de la matriz común.
Pero, en mi opinión, no es universal. El usuario no entiende qué parámetros de la base GAttribBase se utilizan para la representación de tal o cual control.
Para que el codificador sepa exactamente qué color debe cambiar tendría que buscar en la función de renderizado del control, lo que es realmente molesto.
-----
De todos modos, alguna idea para que el codificador se libere de la gestión del color (para usar colores predefinidos directamente y no molestarse con ellos al principio).
Por otro lado, si quiere volver a colorear algunos de los controles de la pantalla, no tiene que investigar qué GAttribBase se utiliza y en qué caso.
@Igor Volodin, @Combinator, @Anatoli Kazharski
En general, ¿qué ideas tienes para que el codificador no tenga que trabajar con los colores, por un lado (para que utilice los colores establecidos directamente y no se moleste con ellos al principio)?
Y por otro lado, si quieren volver a colorear algunos de los controles de la pantalla, pueden hacerlo sin tener que entrar en el laberinto de funciones de dibujo y buscar qué GAttribBase se utiliza y en qué caso.
Bien, temas.
Por ejemplo, el objeto principal de nuestra aplicación, llamémoslo App, está asociado al objeto ConcreteTheme.
Qué es un objeto temático:
colores (fondo, primer plano, desactivado, activo, etc.), tamaños de base, tamaños de letra para casos estándar: titlesize, commonsize, etc. sprites para: paneles, botones, casillas de verificación, etc.
Un nuevo tema es una nueva clase/estructura con valores modificados. Pero es mejor que los temas puedan ser heredados anulando sólo ciertos parámetros.
El resto - la jerarquía de controles en la que cada controlador utiliza uno de los valores necesarios del objeto-tema por defecto. Si necesita anular esto, llamamos a un método para trabajar con esa propiedad, especificando el nuevo valor.
Por ejemplo, SetBgColor(XRGB(255,0,128));
CView - una clase básica que proporciona una interacción básica basada en eventos
- CRect - coordenadas
- Cpanel tiene un bgcolor
- CButton tiene un objeto de estado, cada estado tiene bg
- CText tiene un color de texto y propiedades de fuente
- Círculo CC
Y así sucesivamente.
Si quieres usar xml para describir los elementos,
entonces para cada clase control o primitiva necesitamos crear una clase generadora llamémosla "build-container" que mapeará los atributos (bgcolor="(255,0,128)" a los métodos correspondientes ( SetBgColor(attrValue) ) de la clase. Tales contenedores de construcción serán analizados por el analizador XML, la salida será un objeto inicializado con los valores necesarios, o con los predeterminados si no se especificaron valores.
Aquí el tema es el mismo que el mío - un conjunto de GAttributors para diferentes tipos de controles y sus estados.
pero ya sugieres el primer paso en el camino hacia la transparencia para el codificador - añadir funciones a un control específico para cambiar sus propiedades de representación (SetBgColor etc.)
Básicamente estoy de acuerdo, quedará claro qué colores tiene y qué se puede cambiar.
entonces, ¿el tema implica la redundancia de los parámetros no utilizados?
Digamos que en mi GAttribBase básico para algún control (por ejemplo, botón) utilizamos sólo el color de fondo y el tamaño, y otros parámetros - grosor del borde, etc. no se utilizan en este control.
Es decir, ¿tiene un elemento base para todos los controles? ¿dónde se almacena la información "para todos los casos", o todos los controles tienen sólo sus parámetros sin la sobrecarga de universalidad?
...
En general, ¿cuáles son algunas ideas para que el codificador no tenga que manejar los colores (para que utilice los colores por defecto y no se moleste con ellos al principio)?
Y por otro lado - para que si quiere volver a colorear algún controlador en la pantalla, no tenga que bucear en el desierto de las funciones de renderizado y averiguar qué GAttribBase se utiliza y en qué caso.
Establezca los valores por defecto para cada elemento. Si el usuario necesita cambiar algo, para cada propiedad del elemento debe haber un método para establecer el nuevo valor. Así es como lo tengo hecho ahora.
Todavía no tengo esto:
Pero todo esto es mi razonamiento con respecto a mi esquema. No descarto que todavía cambie mucho cuando empiece la transición. Así que todo lo que escribí anteriormente puede no ser relevante para el tema que se está discutiendo aquí. )