¿Existe una tendencia para los kits de herramientas GUI multiplataforma? [cerrado]
12
¿Cuál es la tendencia para el uso de marcos de GUI multiplataforma en este momento? ¿Están comenzando a utilizar más marcos multiplataforma (como GTK +, Qt y wxWidgets) o hay más que usan marcos vinculados a la plataforma (por ejemplo, Cocoa o WPF)? ¿Está más o menos estancado? ¿Es como una montaña rusa? ¿Cómo crees que será la tendencia, digamos, dentro de 5 años?
El panorama del sistema operativo está cambiando con menos personas que usan Windows (observación personal). Esto debería aumentar la demanda de kits de herramientas multiplataforma, ¿no?
Editar: Además, ¿qué kits de herramientas (multiplataforma) están creciendo más, si es así?
Casi parece que hay una tendencia contra los kits multiplataforma. Si las personas quieren escribir una vez, ejecutar en cualquier lugar, tienden a usar HTML: crear un sitio web. Las personas solo usan los juegos de herramientas de la plataforma cuando se requiere una apariencia nativa, por ejemplo, en el iPhone. Entonces, si la razón por la que te estás molestando con la aplicación que no es web es para obtener una apariencia nativa, no tiene mucho sentido usar un kit multiplataforma.
Los juegos de herramientas multiplataforma nunca han funcionado tan bien; Las plataformas de escritorio no son tan similares, y es difícil abstraerlas realmente. Agregar teléfonos y tabletas a la mezcla lo hace aún más difícil. Terminas con una abstracción muy permeable (ver http://www.joelonsoftware.com/articles/LeakyAbstraction.html ). A menudo es más fácil separar muy bien su "motor" de su interfaz de usuario y escribir la interfaz de usuario por plataforma.
La tendencia para que Mac sea más popular podría hacer que los kits multiplataforma sean menos populares en lugar de más. Creo que a menudo la gente usaba un kit multiplataforma más para marcar teóricamente la casilla de verificación multiplataforma que para obtener resultados realmente buenos en todas las plataformas. Una vez que realmente te interesan las plataformas múltiples ... comienzas a ver cómo los kits multiplataforma tienen desventajas.
Creo que es revelador que muchas de las aplicaciones multiplataforma grandes y populares inventen su propio enfoque multiplataforma (Firefox, Chrome, Eclipse, OpenOffice.org son ejemplos que se me ocurren). Al ser propietarios del marco, pueden atravesar la abstracción cuando sea necesario. Además, todas estas aplicaciones tienden a tener el mismo aspecto (y no especialmente nativas) en todas las plataformas.
Dicho todo esto, no tengo estadísticas reales ni nada. Pero he trabajado mucho en GTK + y estoy familiarizado con las bases de códigos, incluidos Firefox, Chrome y Eclipse. Así que he visto los desafíos técnicos aquí de primera mano.
Hubiera dicho esto simplemente como "La tendencia de los kits de herramientas multiplataforma es hacia el fracaso".
ohmantics
14
De hecho, ha habido una tendencia hacia un juego de herramientas de interfaz de usuario multiplataforma en los últimos años. Ese kit de herramientas es HTML / CSS / JavaScript.
Es muuuucho más simple de desarrollar una vez y lo he visto correr casi de manera idéntica en todas partes.
Y sí, los desarrollos se están alejando masivamente del escritorio a la web. Lo ves tú mismo.
+1 Para la web como una tendencia creciente de IU, pero no creo que esto aborde la pregunta del OP.
Totalmente de acuerdo. Desarrollamos nuestra aplicación de IPTV en el cuadro Settop completamente usando HTML5 / CSS3 / JavaScript. Ese es el futuro, no otro marco masivo y completo de C / C ++
Ernelli
1
Una buena mención, pero en realidad estoy interesado en los kits de herramientas de escritorio multiplataforma . Todavía votado.
Anto
@Anto: puede agregar eso a su pregunta. Después de leer, no aprendí nada sobre el "escritorio". Por supuesto, soy un programador web y no reconocí la mayoría de los marcos que mencionaste :)
Marcie
@Anto, es posible que desee mencionar el escritorio en su pregunta.
JBRWilkinson
7
Tiendo a usar kits de herramientas multiplataforma porque tienen un mejor diseño, no porque estoy tratando de ser multiplataforma. Por ejemplo, trabajo en proyectos escritos en C ++ dirigidos solo a la plataforma Windows. ¿Utilizo win32 o MFC, prácticamente las ÚNICAS opciones disponibles para el kit de herramientas nativo?
Santo cielo, no! ¡Son prácticamente los peores montones de basura de espagueti que he visto! El acoplamiento directo del sistema de eventos con el sistema de "mensajes" del sistema operativo subyacente es increíblemente poco intuitivo y carece de la expresividad necesaria para crear rápidamente programas de interfaz de usuario. Las abstracciones de nivel superior, actualmente solo proporcionadas por kits de herramientas multiplataforma, son absolutamente esenciales para la tarea.
Ese es solo un ejemplo también. Podría seguir y seguir la lista de cosas que se hacen mejor con kits de herramientas multiplataforma. El hecho es que las interfaces gráficas son más similares entre sí que distintas. Hay muy poca diferencia entre un programa de Windows en Windows frente a uno en Linux, por ejemplo. El tipo de cosas que haces al hacer programas de interfaz de usuario son casi siempre exactamente las mismas, sin importar a qué sistema operativo estés apuntando ... y solo pequeñas diferencias entre arquitecturas como teléfono / palm vs. escritorio. El campo simplemente se ha centrado en las metodologías multiplataforma porque a) es necesario para mucha gente yb) es todo lo mismo.
Un argumento en contra de producir un marco multiplataforma es que siempre estará dirigido al mínimo común denominador: los clientes del marco quieren escribir código solo una vez y se ejecuta 'en todas partes'. Entonces, una increíble plataforma de hardware se parecería a cualquier otra plataforma que ejecute ese marco ya que no puede aprovechar las características específicas de la plataforma.
Con el tiempo, esto desafortunadamente resulta en marcos inclinados hacia su plataforma más popular y pirateando el soporte para las otras plataformas, o simplemente eliminándolos cuando se agota el presupuesto / popularidad.
Una forma de capitalizar las capacidades específicas de la plataforma es tener algo así como una #if PLATFORM_FEATURE_Xconstrucción en torno a todo el código específico o verificaciones equivalentes de tiempo de ejecución que resultan en una hinchazón del código. Esto se vuelve tedioso con bastante rapidez, ya que las variantes de la misma plataforma necesitarán un manejo específico. Por ejemplo, algunos XBox v1 no tenían disco duro, por lo que los juegos que usan herramientas multiplataforma no podían usarlo para el almacenamiento en caché, en comparación con una versión para PC que puede garantizar un disco duro.
Para las aplicaciones de escritorio / productividad, la apariencia de la plataforma parece ser importante, pero muchas aplicaciones tienen su propio estilo, por lo que no es un problema tener el mismo aspecto en todas las plataformas, por ejemplo, aplicaciones creadas con AIR.
Los proveedores de hardware como Apple, Sony, Nintendo y Toshiba querrán asegurarse de que sus productos hagan algo para diferenciarse de la competencia, por ejemplo, Touch, Acelerómetros / Gryoscopes, Blu-Ray, pantalla 3D. Es poco probable que haya una plataforma con todas las características de todos los competidores en una sola (debido al costo y la complejidad), por lo que uno ganará.
De hecho, ha habido una tendencia hacia un juego de herramientas de interfaz de usuario multiplataforma en los últimos años. Ese kit de herramientas es HTML / CSS / JavaScript.
Es muuuucho más simple de desarrollar una vez y lo he visto correr casi de manera idéntica en todas partes.
Y sí, los desarrollos se están alejando masivamente del escritorio a la web. Lo ves tú mismo.
fuente
Tiendo a usar kits de herramientas multiplataforma porque tienen un mejor diseño, no porque estoy tratando de ser multiplataforma. Por ejemplo, trabajo en proyectos escritos en C ++ dirigidos solo a la plataforma Windows. ¿Utilizo win32 o MFC, prácticamente las ÚNICAS opciones disponibles para el kit de herramientas nativo?
Santo cielo, no! ¡Son prácticamente los peores montones de basura de espagueti que he visto! El acoplamiento directo del sistema de eventos con el sistema de "mensajes" del sistema operativo subyacente es increíblemente poco intuitivo y carece de la expresividad necesaria para crear rápidamente programas de interfaz de usuario. Las abstracciones de nivel superior, actualmente solo proporcionadas por kits de herramientas multiplataforma, son absolutamente esenciales para la tarea.
Ese es solo un ejemplo también. Podría seguir y seguir la lista de cosas que se hacen mejor con kits de herramientas multiplataforma. El hecho es que las interfaces gráficas son más similares entre sí que distintas. Hay muy poca diferencia entre un programa de Windows en Windows frente a uno en Linux, por ejemplo. El tipo de cosas que haces al hacer programas de interfaz de usuario son casi siempre exactamente las mismas, sin importar a qué sistema operativo estés apuntando ... y solo pequeñas diferencias entre arquitecturas como teléfono / palm vs. escritorio. El campo simplemente se ha centrado en las metodologías multiplataforma porque a) es necesario para mucha gente yb) es todo lo mismo.
fuente
Un argumento en contra de producir un marco multiplataforma es que siempre estará dirigido al mínimo común denominador: los clientes del marco quieren escribir código solo una vez y se ejecuta 'en todas partes'. Entonces, una increíble plataforma de hardware se parecería a cualquier otra plataforma que ejecute ese marco ya que no puede aprovechar las características específicas de la plataforma.
Con el tiempo, esto desafortunadamente resulta en marcos inclinados hacia su plataforma más popular y pirateando el soporte para las otras plataformas, o simplemente eliminándolos cuando se agota el presupuesto / popularidad.
Una forma de capitalizar las capacidades específicas de la plataforma es tener algo así como una
#if PLATFORM_FEATURE_Xconstrucción en torno a todo el código específico o verificaciones equivalentes de tiempo de ejecución que resultan en una hinchazón del código. Esto se vuelve tedioso con bastante rapidez, ya que las variantes de la misma plataforma necesitarán un manejo específico. Por ejemplo, algunos XBox v1 no tenían disco duro, por lo que los juegos que usan herramientas multiplataforma no podían usarlo para el almacenamiento en caché, en comparación con una versión para PC que puede garantizar un disco duro.Para las aplicaciones de escritorio / productividad, la apariencia de la plataforma parece ser importante, pero muchas aplicaciones tienen su propio estilo, por lo que no es un problema tener el mismo aspecto en todas las plataformas, por ejemplo, aplicaciones creadas con AIR.
Los proveedores de hardware como Apple, Sony, Nintendo y Toshiba querrán asegurarse de que sus productos hagan algo para diferenciarse de la competencia, por ejemplo, Touch, Acelerómetros / Gryoscopes, Blu-Ray, pantalla 3D. Es poco probable que haya una plataforma con todas las características de todos los competidores en una sola (debido al costo y la complejidad), por lo que uno ganará.
fuente