Interfaz gráfica de usuario de origen colectivo. Prueba beta abierta. - página 27

 
Tengo que admitir que no todos los objetivos se han cumplido a partir del día 3. Las funciones de añadir y quitar ventanas no están terminadas. El borrado de elementos no funciona. Hay errores. Un fallo grave del que no me di cuenta ayer, lo arreglaré hoy y lo volveré a publicar. Sin embargo, ya hay suficiente funcionalidad para construir y conectar un panel sencillo. Todo el proceso dura unos minutos.
 
He decidido terminar las funciones básicas y publicarlas en ese momento. Las tareas son claras: necesito un modo de edición en paralelo para múltiples ventanas junto con la adición/eliminación de elementos y la carga selectiva de proyectos.

Publicaré el editor después de que resuelva el primer problema y empiece a hacer pruebas públicas. No puedo comprobarlo todo yo sola y necesito ayudantes. Nikolay, Alexey y otros participantes del tema, por favor no desaparezcan. Juntos daremos un gran paso adelante.
 
Алексей Барбашин:

No va a ninguna parte. La interacción entre las dos lógicas aún está por construir. La vista no existe por sí misma. Algunos de sus elementos están siempre ligados a variables y/u objetos del propio modelo de aplicación.

Tienes razón en todo, Alexey. Sólo hay un problema: no reconoces "la misma Fedora, con otro vestido" en cuanto a objetos y enfoque en general.

Los problemas de interacción entre las dos lógicas ya están resueltos y ocultos en la funcionalidad del motor del plugin. El usuario recibe funciones para controlar los elementos y no necesita mirar mi código. Entonces, todo está bien.
 
Реter Konow:
Tienes razón en todo, Alexey. Sólo hay un problema: no reconoces "la misma Fedora con otro vestido" con respecto a los objetos y al enfoque en general.

Los problemas de interacción entre las dos lógicas ya han sido resueltos y están ocultos en la funcionalidad del motor de los complementos. El usuario recibe funciones de control de elementos y no necesita mirar mi código. Entonces, todo está bien.

Esperaremos y veremos. Hasta ahora veo una flagrante sustitución de conceptos. Todos los conceptos de programación de los últimos años se han vuelto del revés.

Pero esperemos el resultado, no lo cortemos en caliente.

 
Алексей Барбашин:

Ya veremos. Lo que veo hasta ahora es una burda sustitución de conceptos. Todos los conceptos de programación de los últimos años se han vuelto del revés.

Pero esperemos el resultado, no lo cortemos en caliente.

Bien, y si el resultado justifica la inversión de los conceptos generalmente aceptados, ¿entonces qué?
 
Реter Konow:
Pues bien, si el resultado justifica una inversión de los conceptos aceptados, ¿qué ocurre entonces?

Extraña pregunta. ¿Qué esperabas?

Estoy 100% seguro de que no...

 
Алексей Барбашин:

Extraña pregunta. ¿Qué esperabas?

Estoy 100% seguro de que no...

Pues entonces se ha nombrado bien y no hay duda.

No hay nada que discutir. El resultado ya está ahí y habrá más. Probémoslo tal y como lo habíamos planeado y hagamos una buena obra para la comunidad.

Zy. Sin embargo, puedes negarte.
 
¿A quién le importa ya mi enfoque? ¿Qué clase de dogmatismo es éste? ¿Adorar a un grupo de científicos anglosajones que proyectan su propia visión subjetiva de un objeto y que siempre son secundarios, pensando que tienen el monopolio de la introducción de conceptos en la programación? ¿Y si alguien más genial que ellos puede filosofar y presentar el objeto de una manera más sencilla y eficiente? ¿Y si alguien quiere escribir un programa en su propio idioma?

Ah, no importa. Si el ego está poniendo un radio en la rueda aquí, entonces de qué sirve el resultado...
 
Por supuesto, resolveré las tareas que se me presenten. Se encontrarán los probadores.
 

Peter, tienes una reacción muy interesante, como se dice "y luego Ostap se dejó llevar". Hay notas de cierto resentimiento infantil y primitivo. ¿Pero a qué?

Simplemente escribí que no creo que la tergiversación de los conceptos convencionales justifique el resultado.

Si he entendido bien, no se trata de desarrollar un sistema independiente, sino un conjunto de herramientas para otros programadores.

Pero otros programadores, usuarios potenciales de su producto ya en esta fase, dicen: ¡Peter, esto no está bien! Tú, en respuesta, dices: "¡Pero si sois todos unos incompetentes, no tenéis ni puta idea de programación y os habéis inventado de alguna manera el RPF y las clases! Pero en realidad todo es sencillo y fácil de hacer en ensamblador. Terminaré mi producto y os enseñaré nuevas reglas de programación, si no, ¡todos jugáis en una caja de arena y no veis más allá de vuestra nariz!"

De alguna manera, todo suena así.

Pero no entiendes el punto principal: los que van a usar tu producto según tu idea, tienen una comprensión completamente diferente de la programación y del concepto de "objeto", del modelo de eventos, de las suscripciones a eventos, de la herencia, etc. Será muy difícil para ellos pasar de los paradigmas convencionales a un producto único con algunos giros.

Estoy seguro de que el editor en sí será excelente, no hay duda de ello. Como producto independiente se puede respetar e incluso se puede jugar con él como constructor. Pero aprender algo nuevo, como un "lenguaje de marcas", sólo para conectar la interfaz gráfica de usuario a su código, no sería rentable.

Has hecho un gran trabajo al crear un constructor gráfico. Fíjate en que absolutamente todo el mundo te apoya en esta dirección.

Y prácticamente todo el mundo te dice: Pedro, todo esto estaría en demanda si reescribes todo en OOP. Pero no me escuchas. Aparentemente, creas un producto estrictamente para satisfacer tu ego, en lugar de para otros usuarios, cuyos intereses ignoras descarada y abiertamente.

Bueno, hablando de la lengua rusa, también aquí no es un pionero. La empresa rusa 1C lleva mucho tiempo desarrollando un lenguaje de programación principalmente en ruso.