Estoy escribiendo una aplicación que actualmente tiene una GUI de SWT, pero me gustaría que los usuarios finales puedan elegir entre SWT y Swing. He experimentado con abstraer los detalles de la GUI antes en diferentes capas del programa, pero nunca he estado realmente satisfecho con los resultados. ¿Hay una forma acordada o agradable de hacer esto?¿Hay alguna manera de abstraer la GUI para poder usar SWT o Swing?
Lamentablemente, no creo que haya una API agnóstica de herramientas o similar.
Así que tal vez vale la pena mirar el patrón model-view-controller. Debe abstraer la mayor parte de la funcionalidad de la GUI al controlador, de modo que los componentes de la GUI sean delgados y estén dedicados al conjunto de herramientas de ventanas particular que haya elegido.
Esto le permitirá colocar una vista de Swing en lugar de una vista de GWT (o viceversa) con el mínimo de código duplicado.
Tenga en cuenta también que esto hace que la prueba de un lote sea más fácil, ya que la mayor cantidad posible se ha plegado en el controlador o modelo.
¿Existe alguna forma acordada o interesante de abstraer el código específico de la GUI?
La respuesta, en resumen, es no.
El problema al usar cualquier biblioteca de GUI en particular es que cada GUI viene con un conjunto de principios básicos de diseño que influyen en cada uso de la biblioteca. A menos que uno se encuentre con dos de tales bibliotecas que concuerden en cada detalle en estos principios de diseño, no hay una sustitución simple de una GUI por otra.
Hay una serie de bibliotecas que intentan imponer su diseño sobre un grupo de GUI dispares debajo de cada una con su propio diseño, pero estas bibliotecas requieren cantidades feroces de programación. Además, el intento de forzar a un conjunto de paradigmas de diseño a otro no suele ser completamente exitoso.
Ejemplos de estas bibliotecas son QT, wxWidgets y, por supuesto, el AWT base de Java.
Al final, casi tiene que aceptar que va a elegir una biblioteca y atascarse con ella.
Si su único objetivo es permitir que los usuarios elijan entre SWT o Swing dibujando su UI, entonces SWTSwing habría sido una opción. Podría codificar en SWT y elegir el contenedor de implementación de SWT durante el inicio y adaptar su ruta de clases según corresponda.
SWTSwing es una implementación de la API de SWT utilizando Swing. Hace lo mismo que hace cada implementación SWT nativa: proporciona el puente a la API GUI subyacente.
¿Por qué escribo "habría sido"? Lamentablemente, el proyecto parece muerto, atrapado en una implementación inacabada de SWT-3.2, aunque parece que se ha hecho mucho trabajo, como se puede ver en la demostración de webstart. El proyecto hermano EoS (Eclipse en Swing) tenía incluso un prototipo en ejecución. Entonces realmente no puedo recomendar usarlo, aunque me gusta la idea.
Sí, usando SwingWT, una implementación de Swing usando SWT como back-end.
Muchas personas prefieren las API de Swing de alto nivel, pero SWT usa widgets nativos. Esta biblioteca aparentemente te da ambas cosas.
También permite que las aplicaciones Swing se ejecuten sin modificaciones usando un back end de SWT (ya que su programa ya está escrito utilizando SWT que no lo ayuda, pero lo hará con otras). De acuerdo con la descripción, la implementación funciona utilizando un cargador de clases personalizado que reemplaza las llamadas Swing con llamadas a SwingWT. Debería ser posible dejar que el usuario seleccione si hacer esto.
El autor no parece estar desarrollándolo activamente, pero todavía está revisando/aplicando parches recibidos de otros (más recientemente, a principios de 2012).
Conocía este proyecto, y estoy triste de que esté muerto :( – ZoFreX