java - plugin - swing windowbuilder
Aplicación Java Desktop: SWT vs. Swing (10)
Interesante pregunta. No sé demasiado bien SWT para alardear de ello (a diferencia de Swing y AWT), pero aquí está la comparación hecha en SWT / Swing / AWT.
Y aquí está el sitio donde puedes obtener un tutorial sobre básicamente cualquier cosa en SWT ( http://www.java2s.com/Tutorial/Java/0280__SWT/Catalog0280__SWT.htm )
Espero que tomes una decisión correcta (si hay decisiones correctas en la codificación) ... :-)
Soy un desarrollador web en el día y estoy pensando en construir mi primera aplicación de escritorio real. La idea es crear una herramienta que automatice una tarea muy repetitiva en una aplicación web donde no hay API disponible.
Sé que quiero usar Java. Lo utilicé antes para cosas web, conozco la sintaxis bastante bien y quiero que la aplicación sea lo más fácil posible.
De lo que no estoy tan seguro es si debería usar SWT o Swing. Como mi audiencia principal usa Windows, quiero buscarla como nativa allí. Linux y Mac deberían funcionar, pero las apariencias no son tan importantes aquí.
Entonces, ¿cuáles son los argumentos a favor y en contra de cada Marco de interfaz de usuario, Swing o SWT?
Gracias.
PD: desarrollo en Windows usando Eclipse. Pero estaba pensando en jugar con Netbeans.
Para sus requisitos, parece que lo más importante será utilizar Swing, ya que es un poco más fácil de empezar y no está tan bien integrado a la plataforma nativa como SWT.
Swing generalmente es una apuesta segura.
SWT fue creado como una respuesta a la lentitud de Swing en el cambio de siglo. Ahora que las diferencias en el rendimiento se vuelven insignificantes, creo que Swing es una mejor opción para sus aplicaciones estándar. SWT / Eclipse tiene un marco agradable que ayuda con un montón de código de placa de caldera.
Si planea construir una aplicación funcional completa con más de un puñado de características, le sugiero que vaya directamente al uso de Eclipse RCP como marco.
Si su aplicación no crece demasiado o sus requisitos son demasiado únicos como para ser manejados por un marco comercial normal, puede saltar de manera segura con Swing.
Al final del día, te sugiero que pruebes ambas tecnologías para encontrar el traje que mejor te parezca. Al igual que Netbeans vs Eclipse vs IntelliJ, no existe la respuesta correcta absoluta aquí y ambos marcos tienen sus propios inconvenientes.
Pro Swing:
- mas expertos
- más parecido a Java (casi no hay campo público, no hay necesidad de disponer en el recurso)
Pro SWT:
- más SO nativo
- Más rápido
Una cosa a considerar: lectores de pantalla
Por alguna razón, algunos componentes de Swing no funcionan bien cuando se usa un lector de pantalla (y Java AccessBridge para Windows). Sepa que diferentes lectores de pantalla producen un comportamiento diferente. Y en mi experiencia, el SWT-Tree funciona mucho mejor que el Swing-Tree en combinación con un lector de pantalla. Por lo tanto, nuestra aplicación terminó usando tanto componentes SWT como Swing.
Para distribuir y cargar la biblioteca SWT apropiada, puede encontrar útil este enlace: http://www.chrisnewland.com/select-correct-swt-jar-for-your-os-and-jvm-at-runtime-191
Una cosa importante a considerar es que algunos usuarios y algunos revendedores (Dell) instalan una máquina virtual de 64 bits en su Windows de 64 bits, y no puede usar la misma biblioteca SWT en las máquinas virtuales de 32 y 64 bits.
Esto significa que deberá distribuir y probar diferentes paquetes según si los usuarios tienen Java VM de 32 o 64 bits. Vea este problema con Azureus, por ejemplo, pero también lo tiene con Eclipse, donde a partir de hoy las versiones en la página de descarga frontal no se ejecutan en una máquina virtual de 64 bits.
Usaría Swing por un par de razones.
Ha existido por más tiempo y se le han aplicado más esfuerzos de desarrollo. Por lo tanto, es probable que haya más características completas y (tal vez) tenga menos errores.
Hay mucha documentación y otra orientación sobre la producción de aplicaciones de rendimiento.
- Parece que los cambios en Swing se propagan a todas las plataformas simultáneamente, mientras que los cambios en SWT parecen aparecer primero en Windows, luego en Linux.
Si desea construir una aplicación con muchas funciones, es posible que desee comprobar NetBeans RCP (Rich Client Platform). Hay una curva de aprendizaje, pero puedes armar buenas aplicaciones rápidamente con un poco de práctica. No tengo suficiente experiencia con la plataforma Eclipse para emitir un juicio válido.
Si no desea utilizar todo el RCP, NetBeans también tiene muchos componentes útiles que se pueden extraer y usar de forma independiente.
Otra palabra de consejo, mira en diferentes administradores de diseño. Me hicieron tropezar durante mucho tiempo cuando estaba aprendiendo. Algunos de los mejores ni siquiera están en la biblioteca estándar. Las MigLayout (para Swing y SWT) y JGoodies Forms son dos de las mejores en mi opinión.
Yo elegiría swing simplemente porque es "nativo" para Java.
Además, eche un vistazo a http://swingx.java.net/ .
swing profesional:
- La mayor ventaja de swing en mi humilde opinión es que no necesita enviar las bibliotecas con su aplicación (lo que evita una docena de MB (!)).
- La apariencia nativa es mucho mejor para el swing que en los primeros años
- el rendimiento es comparable a swt (¡el swing no es lento!)
- NetBeans ofrece a Matisse un constructor de componentes cómodo.
- La integración de los componentes Swing dentro de JavaFX es más fácil.
Pero en la línea de fondo, no recomendaría usar swing o swt ''puro'' ;-) Hay varios frameworks de aplicaciones para swing / swt out. Mira aquí . Los jugadores más importantes son netbeans (swing) y eclipse (swt). Otro buen marco podría ser griffon y un buen "conjunto de componentes" es pivote (swing). Griffon es muy interesante porque integra muchas bibliotecas y no solo swing ; también pivote, swt, etc.
Pros Swing:
- parte de la biblioteca de Java, no hay necesidad de bibliotecas nativas adicionales
- funciona de la misma manera en todas las plataformas
- Editor de GUI integrado en Netbeans y Eclipse
- buenos tutoriales en línea por Sun / Oracle
- Compatible con extensiones oficiales de Java (como OpenGL java)
Contras Swing:
- La apariencia y comportamiento nativos pueden comportarse de manera diferente al sistema nativo real.
- los componentes pesados (nativos / awt) ocultan los componentes del columpio, no es un problema la mayor parte del tiempo, ya que el uso de componentes pesados es bastante raro
Pros SWT:
- utiliza elementos nativos cuando es posible, por lo que siempre el comportamiento nativo
- compatible con eclipse, el editor de GUI VEP (VEP también admite Swing y AWT)
- gran cantidad de ejemplos en línea
- tiene un puente awt / swt integrado para permitir el uso de componentes awt y swing
Contras SWT:
- requiere bibliotecas nativas para cada sistema compatible
- puede no admitir todos los comportamientos en todos los sistemas debido a los recursos nativos utilizados (opciones de sugerencia)
- administración de recursos nativos, mientras que los componentes nativos a menudo se eliminarán con otros recursos principales, como Fonts, que se deben liberar o registrar manualmente para disponer de un agente de escucha para un lanzamiento automático.