¿Por qué es difícil hacer que un programa Java "parezca nativo"?

La mayoría de las aplicaciones Java no tienen el mismo aspecto que las aplicaciones C / C ++. Swing podría haber sido diseñado a propósito para tener un aspecto distintivo, pero basado en lo que he leído, SWT por ejemplo intentó "parecer nativo", y no tuvo éxito por completo.

Mi pregunta es:

¿Por qué es difícil para los desarrolladores del lenguaje Java diseñar un sistema GUI que copie exactamente el aspecto de las GUI nativas? ¿Qué es diferente en las GUI nativas? ¿No es solo una cuestión de diseñar botones que se vean como botones 'nativos'? ¿O va más profundo que eso?

¿No es solo una cuestión de diseñar botones que se vean como botones 'nativos'?

Bueno, más o menos, para botones. Pero esto podría ser más difícil de lo que imaginas. En estos días, los gráficos utilizados para representar los componentes de la GUI no son tan simples como mapas de bits aleatorios que se estiran (ya que estos no se escalan muy bien), a menudo son gráficos basados ​​en vectores con una gran cantidad de casos de esquina programados en ellos ( entonces, cuando el botón llega al borde de la pantalla, puede verse ligeramente diferente, por ejemplo). Y, por supuesto, necesitará diferentes gráficos cuando haga clic en un botón. Por razones de derechos de autor, los desarrolladores a menudo no pueden simplemente usar estos gráficos existentes, por lo que deben volver a crearse, y aunque hacen un buen trabajo en su mayor parte, inevitablemente se pierden algunas cosas debido a la gran variedad de componentes gráficos que existen.

Estoy diciendo todo lo anterior basado en Swing, que es, por supuesto, un kit de herramientas GUI liviano y no nativo. Usted menciona específicamente que SWT no parece nativo, lo cual es un poco extraño, porque SWT es nativo. Es un juego de herramientas que utiliza JNI debajo para llamar a componentes nativos, por lo que si algo no se ve bien allí, no será por la apariencia.

Hay literalmente media docena de juegos de herramientas que podrían considerarse "nativos" en algún sistema. Algunos de estos tienen conceptos o capacidades bastante únicos, y replicarlos en un juego de herramientas multiplataforma es tedioso. La apariencia de una aplicación no solo está determinada por una "máscara", sino también por el diseño y cómo se comporta. Algunas consideraciones

• En un cuadro de diálogo, ¿a qué lado pertenece el botón "Aceptar", a la izquierda o a la derecha? Justo, construyamos un diálogo separado para cada sistema.
• ¿Cómo marcamos el botón predeterminado en una pantalla? ¿Teñido de color, fuente en negrita, agrandando el botón? Justo, pongamos eso en una hoja de estilo.
• En Windows, el concepto "Ribbon" es bastante nativo. ¿Cómo se traduciría esto a Mac, donde la cinta de opciones no es común? Es justo, olvidemos el diseño exacto de píxeles y proporcionemos una implementación de barra de herramientas diferente para cada sistema.
• ¿Es la barra de menú parte de la ventana (Windows, opcionalmente KDE), o se encuentra en la parte superior de la pantalla (Mac, Unity)? Justo, escribamos una implementación diferente para cada sistema, ya que hemos tirado el diseño exacto de píxeles
• ¿Cómo se representan las fuentes? ¿Tan crujiente como sea posible, o suave y antialias? ¿Y qué fuente se debe usar? Tenga en cuenta que las diferentes fuentes tienen métricas diferentes, por lo que el mismo párrafo representado con el mismo ancho puede tener un número diferente de líneas dependiendo de la fuente.
• ¿El fondo de una ventana es de un solo color, una imagen o un degradado? Pongamos eso en una hoja de estilo también.
• ¿Cómo se ven las barras de desplazamiento? ¿Dónde están los botones, si tienen alguno? ¿Cuán anchos son, o solo se revelan cuando el puntero se mueve a cierta región?
• ¿Cómo incorporamos otros esquemas de color?
• ¿Qué se espera que sea arrastrable? ¿Dónde se esperan los menús contextuales?

Estos problemas no se pueden resolver a través de una hoja de estilo simple cuando tocan el comportamiento o el diseño general de la aplicación. La única solución real es volver a escribir la aplicación para cada sistema (ignorando así los beneficios multiplataforma de Java). La única solución realista es olvidarse del diseño exacto de píxeles y escribir en una interfaz común que abstraiga sobre kits de herramientas específicos del sistema. La solución tomada por Swing es emular varios sistemas, lo que falla espectacularmente.

Y luego está la coherencia multiplataforma, la idea de que su aplicación puede verse exactamente igual en todos los sistemas (a menudo elegidos por juegos, donde esto aumenta la inmersión). En aplicaciones de escritorio, esto es molesto y rompe las expectativas del usuario.

Sí, va más profundo.

Crear un botón que se parece a un botón de Windows u OS X es fácil cuando solo se crea este botón. Pero el botón debe "comportarse" como los originales, lo que puede no ser fácil: tal vez haya más espacio disponible en una versión, pero no en la otra, tal vez el color sea más apropiado para su diseño en la versión de Windows, etc.

Esto se exagera cuando tienes una GUI completa: un programa OS X presenta su contenido de manera diferente a un programa de Windows. Esto es casi imposible de capturar en una GUI: necesitaría dos GUI, pero no muchas aplicaciones hacen tanto alboroto. En cambio, apuntan a "se ve bien en la mayoría de los sistemas"; esto todavía parece algo extraño, pero es utilizable y mucho más fácil de desarrollar.

No es difícil crear un botón que se parezca a un botón OSX, o un botón de Windows, o el de cualquier otro kit de herramientas. Pero las pautas de IU para la mayoría de los entornos no son tan simples como lo básico de "así es como se ve un botón". Existen muchas diferencias más sutiles, desde el espacio entre los elementos de la interfaz de usuario hasta el orden en que ciertas acciones conocidas deberían aparecer en una lista hasta la posición exacta del cuadro de diálogo Preferencias / Opciones en el sistema de menús. Se pueden automatizar los casos más comunes para interfaces de usuario muy simples, pero muchas, si no la mayoría, de las tareas de IU requieren un toque mucho más fino.

SWT trató de automatizar esto hasta cierto punto, y una vez más, lo hace bien para tareas simples de IU. Pero no existe una solución única para todos, por lo que cuando las IU se vuelven más complejas, los métodos básicos que utiliza comienzan a desmoronarse. En general, es posible volver a alinearlo con el trabajo manual de IU, pero esto no es algo que la mayoría de los programadores puedan o estén dispuestos a hacer para todas las plataformas.

El enfoque de Swing para esto fue simplemente evitar kits de herramientas nativas siempre que sea posible. No es nativo, y no intenta serlo: en cambio, intenta crear algo que se verá (casi) igual sin importar dónde se ejecute. En lugar de tratar (en vano) de complacer a todos, trató de complacer a sí mismo, y aunque tuvo éxito en la medida de lo posible, uno puede cuestionar qué tan efectivo es el resultado para la comunidad más amplia de usuarios.

Existe una compensación entre esperar que su aplicación se vea lo más natural posible en cada sistema y esperar que su aplicación funcione de la misma manera en cada sistema. No hay una opción "correcta".

Además, incluso si elige el lado de "aspecto natural", es posible que desee proteger a los usuarios de su kit de herramientas gráficas contra las "mejoras" en los componentes nativos subyacentes y API que podrían romper su aplicación inesperadamente.

Esta es la razón por la cual algunos desarrolladores del kit de herramientas GUI prefieren proporcionar sus propios componentes que imitan los nativos, pero proporcionan su propia implementación. Por otro lado, desarrollar un kit de herramientas GUI funcionalmente completo es un esfuerzo significativo y las consideraciones económicas pueden llevar a cortar algunos bordes.

Tenga en cuenta que este problema no es específico de Java, pero se enfrenta a todas las compañías que producen kits de herramientas independientes de la plataforma.

Todo se debe a la historia.

Sun deseaba que todo el software Java funcionara igual en todas las máquinas.

Para que el software "parezca nativo" tiene que funcionar igual que otro software en el SO dado.

Sun hizo todo lo que estuvo a su alcance para dificultar la escritura del software Java que se integraba con un sistema operativo, ya que cualquier integración con un sistema operativo haría que el software funcionara de manera diferente en cada sistema operativo.

En la actualidad, muy pocos programadores de Java se preocupan por algo que no sea software basado en servidor web.

Sun mató a Java en el escritorio al diseñar todos los programadores que usaban los sistemas basados ​​en Java de Microsoft, haciendo que cualquier programador que eligiera Java en los primeros días se viera mal.

Cualquiera que escribiera software de escritorio que se preocupara por "parecer nativo" aprendió hace mucho tiempo a no usar Java y sus puntos de vista se ven reforzados cada vez que usan cualquier software de Oracle.

Por lo tanto, en estos días no hay demanda de "aparecer nativo" en el software de escritorio de los programadores de Java.

Lo que usted piensa es nativeque en realidad las aplicaciones nativas hacen lo suyo, mientras que los kits de herramientas como SWT siguen los estándares publicados para la interfaz de usuario de ese sistema operativo. El problema es que nadie crea aplicaciones que sigan esos estándares, de modo que cuando se inicia una aplicación Java. Parece no ser nativo. Como ejemplo, casi todos los proyectos de Microsoft (Office, Outlook, etc.) no se pueden reproducir visualmente utilizando los controles estándar de Windows.

Va a empeorar a medida que Microsoft y Apple agreguen características dinámicas de IU a sus plataformas de sistema operativo. Permitiendo a los desarrolladores aplicar máscaras / estilos a sus aplicaciones de la misma manera que los diseños web crean estilos para sitios web.

Java en la plataforma Android está siguiendo este camino. Hacer que los elementos de la IU para Android se definan en XML con estilos personalizables.

Java nunca ha sido tan popular como plataforma de escritorio. Como resultado, estos cambios en la industria no se propagan a los tiempos de ejecución de escritorio. Simplemente no hay suficientes desarrolladores dispuestos a pasar tiempo para solucionar el problema.

¿Qué sistema operativo quieres que parezca "nativo" también?

Simplemente no puedes ser nativo de todos ellos el 100% del tiempo.

SWT, etc., son el enfoque de mejor esfuerzo para lucir tan nativos como todos cuando se necesita llegar a un compromiso .

Y, de hecho, este compromiso comienza a ser cada vez más difícil de alcanzar; no tanto por los sistemas operativos, sino por los dispositivos de entrada. Para las pantallas táctiles, en realidad tiene que diseñar de manera diferente, porque no hay un botón derecho del mouse. Por lo tanto, debe acomodar la misma funcionalidad de lo contrario.

Nunca habrá un botón mágico que mueva la funcionalidad "intuitivamente" desde el botón derecho del mouse hasta los invitados, sin que especifiques todos los aspectos detallados para cada dispositivo de entrada (en ese momento, eres nativo de todas las plataformas que has considerado, pero no obstante -nativo a cualquiera que no haya considerado).

Muy buena pregunta. Siempre me lo pregunté durante algunos años posteriores en el pasado, pensé que había alguna razón legítima detrás de esto, pero realmente no la hay.

Creo que la respuesta es bastante simple, y muchas respuestas no están profundizando en el tema.

Si su idioma permite dibujar piexel en la pantalla, entonces es 100% posible crear un marco gui basado en él que imitará la apariencia de los controles de formulario de Windows con precisión.

Dado que Java es multiplataforma, también es completamente posible asegurarse de que, en función del tipo de sistema en ejecución real (Mac / Windows), la IU elegiría verse diferente en ambas plataformas, coincidiendo con el estilo de la plataforma en tiempo de ejecución.

Como puede ver en XAML, por ejemplo, la IU se puede presentar fácilmente en forma y lenguaje muy estructurados. La elección de los comportamientos "nativos" también es posible si se toma tiempo para hacer esto.

Por lo tanto, sería posible crear un marco GUI que permitiría a los desarrolladores de Java obtener aplicaciones que se verían nativas en Mac y Windows.

Así que llegamos a Swing, que es solo un marco de GUI del potencial infinito de marcos de GUI que podrían crearse para Java. Se comporta como se programó, lo que no sigue el proceso anterior y obtienes aplicaciones de aspecto extraño en ambos sistemas. Esa es la elección hecha por los desarrolladores de Swing, nadie los obligó a hacer esto y a comportarse de esa manera.