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

98

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?

usuario3150201
fuente
31
porque oscilación escribe sus propios componentes GUI que tratan de imitar el nativo, en lugar de crear una unión a los componentes nativos reales, en la idea de la portabilidad
trinquete monstruo
55
No soy un experto en este tema, pero supongo que es solo una cuestión de cuánto esfuerzo están dispuestos a invertir los proveedores del kit de herramientas GUI para obtener todos los detalles correctos. Vea, por ejemplo, el marco de trabajo C ++ "Qt" y esta pregunta SO: stackoverflow.com/questions/7298441/…
Doc Brown
44
Hay muchos detalles para cuidar. Por ejemplo, la forma en que funciona la autocompletado en un cuadro de diálogo de apertura de archivo es un punto en el que una aplicación Java de aspecto nativo se descompuso.
CodesInChaos
44
Swing tiene un aspecto "similar al nativo" que puedes conectar en lugar del predeterminado. Además, Java primero intentó usar cosas nativas disponibles con AWT pero no funcionó muy bien, AFAIK debido a las diferencias inherentes entre las plataformas. Es por eso que crearon Swing, para que una aplicación Java funcione exactamente igual en todas partes.
marczellm 03 de
55
No pase por alto JavaFX. Es el reemplazo de SWING y está en JDK / JRE de manera predeterminada a partir de Java 8. Es mucho más moderno que SWING y AWT y se ve mucho más nativo en casi todas las plataformas (se engancha mucho en el kit de herramientas de interfaz de usuario nativo en cada uno plataforma). Dicho esto, como otros han mencionado, para obtener una aplicación de aspecto exactamente nativa de un lenguaje "único para todos" como Java, tendrá que trabajar un poco. La interfaz de usuario de Java era / eran / aún está pensada para ser una "mejor opción para todas las plataformas" fuera de la caja.
SnakeDoc

Respuestas:

56

¿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.

berry120
fuente
1
Gracias. ¿Qué significa exactamente "peso ligero"? ¿Y qué significa realmente 'nativo'? Supongo que significa algo que usa recursos del sistema operativo de la computadora o interactúa con él directamente. ¿Es esto cierto?
user3150201
1
@ user3150201 Claro, por lo que el SO subyacente tendrá una cantidad establecida de botones y widgets que se pueden colocar de forma nativa, pero obviamente estos botones diferirán entre el SO y las plataformas: estos son los componentes nativos y pesados. Los componentes ligeros no son los componentes dictados por el sistema operativo, están dibujados por Java (en este caso) para que se vean y se comporten como componentes de la GUI, por lo que pueden verse como quieras si pones el trabajo (pero tienes que emular la plataforma se ve y se siente si quieres eso, no lo obtienes gratis.)
berry120
14
La ubicación de los botones, los tamaños exactos y los estilos de GUI preferidos varían según la plataforma y hacer que Java los imite requiere trabajo. Swing puede darle el botón nativo, pero si tiene 10 píxeles de altura, el usuario seguirá pensando que algo está apagado. Apple tiene las Pautas de interfaz humana y Microsoft tiene las Pautas de interfaz de usuario para ayudarlo a obtener el aspecto nativo correcto. Deberá cambiar la interfaz de usuario de alguna manera entre plataformas.
Michael Shopsin
44
JavaFX parece mucho más "nativo" que SWING y AWT. Tiene ventanas transparentes nativas, etc. Un aspecto mucho más moderno y listo para usar.
SnakeDoc
2
@SnakeDoc Parece más moderno, claro, pero no diría que parece "nativo": ciertamente no utiliza los componentes GUI subyacentes de la plataforma, todo está diseñado en CSS.
berry120
71

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.

amon
fuente
1
+1. Solo una cosa que me gustaría agregar: ¿qué pasa con las cosas que el sistema le permite al usuario configurar, comenzando por detalles "simples" como la forma de abrir menús contextuales? (Y preferiría que los programas de Windows tengan cintas y aplicaciones de Mac que no tengan, gracias. Sí, es necesario diseñar buenas GUI por SO).
Christopher Creutzig,
@ChristopherCreutzig De ahí es de donde proviene mi experiencia: en mi escritorio principal, uso KDE en Linux (los cuales son muy configurables), y uso QtCurve para ajustar el aspecto de las aplicaciones. Estos estilos especiales funcionan bien en las aplicaciones insignia de KDE. Las aplicaciones GTK bien escritas pueden utilizar una capa de compatibilidad, pero faltan gradientes de fondo, la barra de menú permanece dentro de la ventana, etc. Pero rápidamente comienza a deteriorarse, con programas que toman algunos widgets del estilo del sistema (como barras de desplazamiento) , pero ignorando a los demás (como el renderizado de fuentes o las sombras alrededor de los menús)
amon
+1 porque hay algunos puntos fuertes en esta respuesta, pero también hay algunos puntos débiles. Cualquier problema de "cómo este administrador de ventanas dibuja X" se maneja utilizando la API nativa. Por ejemplo, X11 en OS X puede dibujar ventanas, botones, barras de desplazamiento, cuadros de diálogo, etc. de OS X nativos, por lo que muchos de esos problemas desaparecen. La verdadera respuesta es lo que @TheSpooniest dijo a continuación: UX es mucho más que solo dibujar widgets. Espaciado, sincronización, animación, aceleración del mouse, entradas táctiles ... hay un mundo de detalles sutiles que son muy caros de reproducir con un juego de herramientas multiplataforma.
Mark E. Haase
13

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.

Christian Sauer
fuente
9

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.

El más cuchara
fuente
7

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.

Nicola Musatti
fuente
En lugar de votar negativamente en silencio, haría un mayor servicio a la comunidad al explicar lo que cree que está mal con una respuesta. A menos que sea solo un problema personal ...
Nicola Musatti
4

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.

Ian
fuente
55
"Sun hizo todo lo que estuvo a su alcance para dificultar la escritura del software de Java que se integró con un sistema operativo", equivocado. Simplemente no hicieron un gran esfuerzo para facilitarlo. "Sun mató a Java en el escritorio al encauzar a todos los programadores que usaban los sistemas basados ​​en Java de Microsoft", la enemistad mutua entre Microsoft y Sun hizo que Microsoft creara una versión de las bibliotecas AWT que no era compatible con los requisitos de Sun, causando la infame Demandas de Sun / MS.
Jwenting
1
@jwenting, Sun se preocupó más por crear problemas para Microsoft que por los programadores que habían elegido usar el sistema basado en Java de Microsoft. Por lo tanto , renuncié a Jave y seguí con MFC hasta que salió C #.
Ian
3
tal vez algunas personas en Sun, pero ese sentimiento era mutuo. Si está desarrollando exclusivamente para una sola plataforma, una herramienta nativa para esa plataforma SIEMPRE es la opción preferida, esto no tiene nada que ver con la política corporativa. Si elige sus herramientas basadas en "Odio a Sun" o "Odio a Microsoft", eso refleja muy mal su actitud profesional. Principalmente he usado Java, pero junto a eso también he usado Delphi, C #, Ruby, C ++, C, Progress, lo que sea mejor para el trabajo en cuestión. Y la mayoría de las veces eso terminará siendo una solución híbrida.
Jwenting
3

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.

Reactgular
fuente
1
+1, en la era de Windows 95 había un aspecto 'estándar' para los controles de Windows. Ahora no tanto.
GrandmasterB
Sí, han pasado algunos años desde que programé el escritorio, pero me sorprendió que .NET no se enviara con un control de estilo de cinta a pesar de que se convirtió en parte integral del software de productividad construido por MS.
Plataforma
@Rig Desde NET 4.0 hay un buen control de cinta nativo en .NET. Aquí hay un buen artículo: c-sharpcorner.com/UploadFile/0b73e1/ribbon-control-in-wpf-4-5
Christian Sauer
1
@Rig Necesitará .NET 4.5, no .NET 4. Visual Studio 2010 solo puede apuntar hasta 4; necesitará VS2012 o más reciente para apuntar a 4.5. Puedo verlo cuando apunto a 4.5 en VS2013, pero no cuando cambio la versión de destino a 4.
Bob
1
@Rig Es posible usar Ribbon en Net 4.0: puede descargarlo de Microsoft y luego aparecerá: 10rem.net/blog/2010/10/22/wpf-ribbon-october-release (No estoy seguro si esto es la última versión) Mejor descárgalo de Nuget. Tuve que hacer eso para un programa que tenía que ejecutarse en Windows XP: funciona bien y es principalmente compatible con la variante Net 4.5, por lo que puede extraer lo 4.0 cuando XP finalmente se retira.
Christian Sauer
-1

¿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).

Anony-Mousse
fuente
-2

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.

Valentin Kuzub
fuente
2
esto no responde a la pregunta, el autor de la pregunta ya cubrió este punto: "Swing podría haber sido diseñado a propósito para tener un aspecto distintivo"
mosquito
No estoy de acuerdo, pero gracias por comentar tu signo negativo (?)
Valentin Kuzub