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

  

¿No es solo cuestión de diseñar botones que se parezcan a botones 'nativos'?

Bueno, más o menos, para los 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 los 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 esquinas programados en ellos ( por lo tanto, cuando el botón llega al borde de la pantalla, puede parecer un poco diferente, por ejemplo. Y, por supuesto, necesitará diferentes gráficos cuando se hace clic en un botón. Por razones de derechos de autor, los desarrolladores a menudo no pueden usar estos gráficos existentes directamente, por lo que tienen que ser recreados, y aunque en general hacen un buen trabajo, inevitablemente algunas cosas se pierden dada la gran variedad de componentes gráficos que existen. Esto es mucho menos grave de lo que solía ser: en estos días, si configuro la apariencia y el estilo de la plataforma predeterminada en Swing, observo que muy poco parece extraño.

Estoy diciendo todo lo anterior basado en Swing, que es, por supuesto, un conjunto de herramientas GUI ligero y no nativo. Menciona específicamente que SWT no parece nativo, lo cual es un poco extraño, porque SWT es nativo. Es un kit de herramientas que utiliza JNI debajo para llamar a componentes nativos, por lo que si algo no se ve bien allí, no lo es. va a ser debido a 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 conjunto de herramientas multiplataforma es tedioso. El look & La sensación de una aplicación no solo está determinada por un "aspecto", 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 lo suficiente, vamos a construir 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 lo suficiente, pongamos eso en una hoja de estilo.
• En Windows, el concepto de "Cinta" es bastante nativo. ¿Cómo se traduciría esto a Mac, donde la cinta de opciones no es común? Justo lo suficiente, olvidemos el diseño exacto de píxeles y proporcionemos una implementación de barra de herramientas diferente para cada sistema.
• ¿La barra de menús es parte de la ventana (Windows, opcionalmente KDE) o se encuentra en la parte superior de la pantalla (Mac, Unity)? Justo lo suficiente, escribamos una implementación diferente para cada sistema, ya que ya hemos desechado el diseño exacto de píxeles
• ¿Cómo se representan las fuentes? ¿Tan crujiente como sea posible, o suave y suavizado? ¿Y qué fuente se debe utilizar? Tenga en cuenta que las diferentes fuentes tienen diferentes métricas, por lo que el mismo párrafo representado al mismo ancho puede tener un número diferente de líneas según la fuente.
• ¿El fondo de una ventana es de un solo color, una imagen o un degradado? También 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? ¿Qué tan grandes son, o solo se revelan cuando el puntero se mueve hacia una determinada 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 se abstrae sobre kits de herramientas específicos del sistema. La solución adoptada por Swing es emular varios sistemas, lo que falla espectacularmente.

Y luego está la consistencia 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 las aplicaciones de escritorio, esto es simplemente molesto y rompe las expectativas del usuario.

Sí, va más profundo.

Crear un botón que parezca un botón de Windows o OS X es fácil, cuando se crea solo este botón. Pero el botón debe "comportarse" como los originales, lo que podría no ser fácil: quizás 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 está excarberado cuando tiene 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 su lugar, buscan "se ve bien en la mayoría de los sistemas", esto aún parece un tanto extraño, pero es fácil de usar y mucho más fácil de desarrollar.

No es difícil hacer un botón que parezca un botón OSX, 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 los conceptos básicos de "esto es lo que parece un botón". Existen muchas diferencias más sutiles, desde el espaciado 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. Uno puede automatizar los casos más comunes para interfaces de usuario muy simples, pero muchas, si no la mayoría de las tareas de UI requieren un toque mucho más preciso.

SWT intentó automatizar esto hasta cierto punto, y una vez más, lo hace bien para tareas de IU simples. 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 un minucioso trabajo manual de IU, pero esto no es algo que la mayoría de los programadores puedan o quieran hacer para todas las plataformas.

El enfoque de Swing para esto fue simplemente evitar los kits de herramientas nativos siempre que sea posible. No es nativo, y no intenta serlo: en su lugar, intenta crear algo que se verá (casi) igual sin importar dónde se ejecute. En lugar de intentar (inútilmente) complacer a todos, trató de complacerse a sí mismo, y aunque tuvo éxito hasta el momento, uno puede cuestionar cuán efectivo es el resultado para la comunidad más amplia de usuarios.

Existe un compromiso 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 la API que podrían romper su aplicación inesperadamente.

Es por esto que algunos desarrolladores de herramientas de GUI prefieren proporcionar sus propios componentes que imitan a los nativos, pero proporcionan su propia implementación. Por otro lado, desarrollar un conjunto 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 juegos de herramientas independientes de la plataforma.

Todo se debe a la historia.

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

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

Sun hizo todo lo posible para dificultar la escritura del software Java integrado 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 estos días, 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 hacer que todos los programadores que usaban los sistemas basados en Java de Microsoft, por lo tanto, hacen que cualquier programador que elija Java en los primeros días se vea mal.

Cualquier persona que escriba software de escritorio que se preocupe por "parecer nativo" aprendió hace mucho tiempo que no debe usar Java y que sus opiniones se refuerzan cada vez que usan cualquier software de Oracle.

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

Lo que piensas que es native es en realidad aplicaciones nativas que 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 siguiendo esos estándares, por lo que al iniciar una aplicación Java. Parece que no es nativo. Como ejemplo, casi todos los proyectos de Microsoft (Office, Outlook, etc.) no se pueden reproducir visualmente usando los controles estándar de Windows.

Se va a poner aún peor a medida que tanto Microsoft como Apple agreguen características dinámicas de UI a sus plataformas de sistema operativo. Permitir que los desarrolladores ajusten / diseñen sus aplicaciones de la misma manera que los diseños web crean estilos para los sitios web.

Java en la plataforma Android sigue este camino. Creación de los elementos de la interfaz de usuario para Android definidos 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 del escritorio. Simplemente no hay suficientes desarrolladores dispuestos a dedicar tiempo a solucionar el problema.

¿Cuál sistema operativo desea que se vea "nativo" también?

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

SWT, etc., es el enfoque de mejor esfuerzo para lucir como nativo de todos ellos como lo es cuando necesitas alcanzar algún 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, realmente tiene que diseñar de manera diferente, porque no hay un botón derecho del mouse. Por lo tanto, necesita 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 huéspedes, sin que usted especifique cada aspecto detallado de cada dispositivo de entrada (en ese momento, usted es nativo a todas las plataformas que haya considerado, pero que no sean nativas a ninguna que haya no considerado).

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

Creo que la respuesta es bastante simple, y muchas respuestas realmente no están investigando el problema.

Si su idioma permite dibujar piexel en la pantalla, es 100% posible crear un marco de interfaz gráfica de usuario basado en él que imitará los controles de formulario de Windows & siente 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 opte por verse diferente en ambas plataformas, coincidiendo con el estilo de la plataforma de ejecución.

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

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

Entonces llegamos a Swing, que es solo un marco de GUI de la infinidad potencial de marcos de GUI que podrían crearse para Java. Se comporta como se programó, lo que no sigue el proceso anterior y obtiene 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 comportarse de esa manera.