El kit de herramientas de widgets estándar ( SWT ) es un kit de herramientas de widgets gráficos para usar con la plataforma Java . Originalmente fue desarrollado por Stephen Northover en IBM y ahora es mantenido por la Fundación Eclipse en conjunto con el IDE de Eclipse . Es una alternativa a los kits de herramientas Abstract Window Toolkit (AWT) y Swing Java Graphical User Interface (GUI) proporcionados por Sun Microsystems como parte de Java Platform, Standard Edition (J2SE).
Autor (es) original (es) | Stephen Northover |
---|---|
Desarrollador (es) | Fundación Eclipse |
Versión inicial | Abril de 2003 |
Lanzamiento estable | 4.19 / 3 de marzo de 2021 |
Repositorio | |
Escrito en | Java |
Sistema operativo | Multiplataforma |
Plataforma | Plataforma Java |
Disponible en | Plurilingüe |
Tipo | Kit de herramientas de widgets para la plataforma Java |
Licencia | Eclipse Público |
Sitio web | www |
Para mostrar elementos de GUI, la implementación de SWT accede a las bibliotecas de GUI nativas del sistema operativo usando la Interfaz nativa de Java (JNI) de una manera similar a los programas escritos usando interfaces de programación de aplicaciones (API) específicas del sistema operativo . Los programas que llaman a SWT son portátiles, pero la implementación del kit de herramientas, a pesar de que parte de él está escrito en Java , es única para cada plataforma.
El kit de herramientas es un software gratuito y de código abierto distribuido bajo la Licencia Pública Eclipse , que está aprobada por la Iniciativa de Código Abierto . [1]
Historia
El primer kit de herramientas de la GUI de Java fue Abstract Window Toolkit (AWT), introducido con Java Development Kit (JDK) 1.0 como un componente de la plataforma Java de Sun Microsystems. El AWT original era una simple biblioteca contenedora de Java en torno a widgets nativos ( suministrados por el sistema operativo ) como menús, ventanas y botones.
Swing fue el conjunto de herramientas de GUI de próxima generación introducido por Sun en Java Platform, Standard Edition (J2SE) 1.2. Swing se desarrolló para proporcionar un conjunto más rico de componentes de software GUI que AWT. Los elementos de la GUI de Swing son exclusivamente Java sin código nativo: en lugar de envolver los componentes de la GUI nativa, Swing dibuja sus propios componentes utilizando Java 2D para llamar a las rutinas de dibujo del sistema operativo de bajo nivel.
Las raíces de SWT se remontan al trabajo que Object Technology International (OTI) hizo en la década de 1990 al crear interfaces de widget nativas, portátiles y multiplataforma para Smalltalk , originalmente para OTI Smalltalk, que se convirtió en IBM Smalltalk en 1993. La capa Common Widget de IBM Smalltalk proporcionó acceso rápido y nativo a conjuntos de widgets de múltiples plataformas, al tiempo que proporciona una API común sin sufrir el problema del mínimo común denominador típico de otros kits de herramientas de interfaz gráfica de usuario (GUI) portátiles. IBM estaba desarrollando VisualAge , un entorno de desarrollo integrado (IDE) escrito en Smalltalk. Decidieron convertir el proyecto en código abierto, lo que llevó al desarrollo de Eclipse , destinado a competir con otros IDE como Microsoft Visual Studio . Eclipse está escrito en Java, y los desarrolladores de IBM, al decidir que necesitaban un conjunto de herramientas que tuviera " apariencia nativa " y " rendimiento nativo ", crearon SWT como reemplazo de Swing. [2]
Diseño
SWT es un envoltorio de objetos de código nativo, como objetos GTK , objetos Motif , etc. Por eso, los widgets SWT a menudo se denominan [¿ por quién? ] como "pesado", evocando imágenes de un contenedor Java ligero alrededor de un objeto nativo "pesado". En los casos en los que las bibliotecas GUI de la plataforma nativa no admiten la funcionalidad requerida para SWT, SWT implementa su propio código GUI en Java, similar a Swing. En esencia, SWT es un compromiso entre el rendimiento de bajo nivel y el aspecto y la sensación de AWT y la facilidad de uso de alto nivel de Swing. [3] [4]
Según la Fundación Eclipse, "SWT y Swing son herramientas diferentes que se crearon con diferentes objetivos en mente. El propósito de SWT es proporcionar una API común para acceder a widgets nativos en un espectro de plataformas. Los principales objetivos de diseño son alto rendimiento, apariencia nativa y una profunda integración de la plataforma. Swing, por otro lado, está diseñado para permitir una apariencia altamente personalizable que es común en todas las plataformas ". [5]
Se ha argumentado [¿ por quién? ] que SWT presenta un diseño limpio, en parte inspirado por la fama de Erich Gamma of Design Patterns . [6]
SWT es un conjunto de herramientas más simple que Swing, con menos (posiblemente) funciones extrañas para el desarrollador promedio. [7] Esto ha llevado a algunas personas [ ¿quién? ] para argumentar que SWT carece de funcionalidad en comparación con Swing. [8]
James Gosling , el creador del lenguaje Java, ha argumentado que SWT es demasiado simple y es un conjunto de herramientas difícil de migrar a nuevas plataformas por la misma razón que AWT una vez tuvo problemas de migración: que es demasiado simple, de muy bajo nivel y demasiado vinculado a la API de la GUI de Win32, lo que genera problemas para adaptar la API de SWT a otros kits de herramientas de la GUI, como Motif y OS X Carbon. [7]
Aunque SWT no implementa la popular arquitectura modelo-vista-controlador (MVC) utilizada en Swing y muchos otros kits de herramientas de GUI de alto nivel, la biblioteca JFace , que se desarrolla como parte del mismo proyecto Eclipse, proporciona una plataforma multiplataforma , superior -level MVC abstracción sobre SWT. Los desarrolladores pueden optar por utilizar JFace para proporcionar modelos de datos más flexibles y abstractos para controles SWT complejos, como árboles, tablas y listas, o acceder a esos controles directamente según sea necesario.
Mira y siente
Los widgets SWT tienen la misma apariencia que los widgets nativos porque a menudo son los mismos widgets nativos. Esto contrasta con el kit de herramientas Swing, donde todos los widgets son emulaciones de widgets nativos. En algunos casos, la diferencia es distinguible. Por ejemplo, el widget de árbol de macOS presenta una animación sutil cuando se expande un árbol y los botones predeterminados en realidad tienen un brillo pulsante animado para enfocar la atención del usuario en ellos. La versión Swing predeterminada de estos widgets no se anima.
Dado que SWT es simplemente un envoltorio alrededor del código GUI nativo, no requiere una gran cantidad de actualizaciones cuando se cambia ese código nativo, siempre que los proveedores de sistemas operativos tengan cuidado de no interrumpir a los clientes de su API cuando se actualizan los sistemas operativos. No se puede decir lo mismo de Swing, que admite la capacidad de cambiar la apariencia de la aplicación en ejecución con "apariencia y funcionalidad conectables". Estos permiten emular la interfaz de usuario de la plataforma nativa utilizando temas , que deben actualizarse para reflejar los cambios de la GUI del sistema operativo, como el tema u otras actualizaciones de apariencia.
SWT apunta a la "integración profunda de la plataforma", la referencia de Eclipse al uso de SWT de widgets nativos. Según Mauro Marinillia de developer.com, "siempre que se necesite una estrecha integración con la plataforma nativa, SWT puede ser un plus". [9] Esta profunda integración puede ser útil de varias formas, por ejemplo, al permitir que SWT envuelva objetos ActiveX en Microsoft Windows .
Programación
El siguiente es un programa básico de Hello World que utiliza SWT. Muestra una ventana ( Shell ) y una etiqueta.
import org.eclipse.swt. * ; importar org.eclipse.swt.widgets. * ;public class HelloWorld { public static void main ( String [] args ) { Display display = new Display (); Shell shell = nuevo Shell ( pantalla ); Etiqueta etiqueta = nueva Etiqueta ( shell , SWT . NINGUNO ); etiqueta . setText ( "Hola mundo" ); etiqueta . paquete (); concha . paquete (); concha . abierto (); while ( ! shell . isDisposed ()) { if ( ! display . readAndDispatch ()) display . dormir (); } pantalla . disponer (); } }
A diferencia de Swing , una clase Display es necesaria para acceder al sistema operativo subyacente , y sus recursos deben eliminarse explícitamente cuando ya no se utilicen.
Soporte de plataforma
SWT debe trasladarse a cada nueva biblioteca GUI que necesite soporte. A diferencia de Swing y AWT, SWT no está disponible en todas las plataformas compatibles con Java, ya que SWT no forma parte de la versión de Java. También hay alguna evidencia de que el rendimiento de SWT en plataformas distintas de Windows es notablemente menos eficiente. [8] Dado que SWT usa una biblioteca nativa diferente para cada plataforma, los programas SWT pueden estar expuestos a errores específicos de la plataforma.
SWT expone los programas a más detalles de bajo nivel que Swing. Esto se debe a que, técnicamente, SWT es solo una capa sobre la funcionalidad GUI provista por la biblioteca nativa, exponer al programador al código GUI nativo es parte de la intención de diseño de SWT: "Su objetivo no es proporcionar un marco de diseño de interfaz de usuario rico, sino más bien el más delgado posible API de interfaz de usuario que se puede implementar de manera uniforme en el mayor conjunto posible de plataformas y, al mismo tiempo, proporcionar la funcionalidad suficiente para crear aplicaciones de interfaz gráfica de usuario (GUI) ricas ". [10]
Dado que la implementación de SWT es diferente para cada plataforma, se debe distribuir una biblioteca SWT específica de la plataforma (archivo JAR) con cada aplicación.
A partir de 2018[actualizar], SWT admite estas plataformas y / o bibliotecas GUI: [11]
- Windows : [12]
- Win32
- Windows Presentation Foundation (WPF), en desarrollo
- Tipo Unix : Linux , FreeBSD :
- GTK
- macOS :
- Cacao
A marzo de 2018[actualizar], SWT 4.7.3a (y 4.8M6) es oficialmente compatible con los siguientes sistemas operativos (biblioteca gráfica o similar si se requiere explícitamente / procesadores): [13]
- Microsoft Windows (x86 y x86_64)
- Linux (GTK / PPC64 y PPC64LE)
- macOS (Cocoa / x86_64)
Históricamente, Windows XP ha sido compatible. La versión anterior también admitía oficialmente s390 , Solaris 11 (SPARCv9), Solaris 10 (x86_64), HP-UX (ia64), AIX (PPC y PPC64). [14]
Actuación
SWT fue diseñado para ser un conjunto de herramientas de GUI de alto rendimiento ; más rápido, más receptivo y más ligero en el uso de recursos del sistema que Swing. [15]
Ha habido algunos intentos de evaluación comparativa de SWT y Swing, que concluyeron que SWT debería ser más eficiente que Swing, aunque las aplicaciones comparadas en este caso no eran lo suficientemente complejas como para sacar conclusiones sólidas para todos los posibles usos de SWT o Swing. [16] Un conjunto bastante completo de puntos de referencia concluyó que ni Swing ni SWT superaron claramente al otro en el caso general. [17]
Extensibilidad y comparación con otro código Java
Debido al uso de código nativo, las clases SWT no permiten una herencia fácil para todas las clases de widgets, lo que algunos usuarios consideran que puede dañar la extensibilidad. [9] Esto puede hacer que la personalización de los widgets existentes sea más difícil de lograr con SWT que si uno estuviera usando Swing. [18] Ambos conjuntos de herramientas admiten la escritura de nuevos widgets utilizando solo código Java, sin embargo, en SWT se necesita trabajo adicional para que el nuevo widget funcione en todas las plataformas. [18]
Los widgets SWT, a diferencia de casi cualquier otro kit de herramientas de Java, requieren la desasignación manual de objetos, en contraste con la práctica estándar de Java de recolección automática de basura . Objetos SWT ha de ser desasignan explícitamente utilizando el dispose
método, que es análogo al lenguaje C 's free
. [19] Si esto no se hace, pueden producirse pérdidas de memoria u otros comportamientos no deseados. Sobre este asunto, algunos han comentado que "la desasignación explícita de los recursos podría ser un paso atrás en el tiempo (y los costos) de desarrollo al menos para el desarrollador promedio de Java" y que "esto es una bendición mixta. Significa más control (y más complejidad) para el desarrollador de SWT en lugar de más automatización (y lentitud) al usar Swing ". [9] La necesidad de una desasignación manual de objetos cuando se usa SWT se debe en gran parte al uso de objetos nativos por parte de SWT. La JVM de Java no rastrea estos objetos, por lo que no puede rastrear si dichos objetos están en uso o no y, por lo tanto, no puede recolectarlos en el momento adecuado.
En la práctica, los únicos objetos SWT que un programa debe eliminar explícitamente son las subclases de recursos, como los objetos Imagen, Color y Fuente. [ cita requerida ]
Desarrollo
Hay alguna actividad de desarrollo para permitir la combinación de Swing y SWT. Se están intentando dos enfoques diferentes:
- SwingWT es un proyecto para proporcionar una implementación alternativa de Swing. Utiliza un back-end SWT para mostrar sus widgets, proporcionando así la apariencia nativa y las ventajas de rendimiento de SWT junto con el mismo modelo de programación que Swing. [20]
- SWTSwing es un proyecto para proporcionar un back-end Swing para SWT. En efecto, SWT podría ejecutarse utilizando objetos nativos de Swing en lugar de, por ejemplo, GTK o objetos nativos de Windows. Esto permitiría que SWT funcione en todas las plataformas compatibles con Swing. [21]
A partir de 2006, hubo un puerto SWT-3.2 para el lenguaje de programación D llamado DWT. [22] Desde entonces, el proyecto es compatible con Windows de 32 bits y Linux GTK de 32 bits para SWT-3.4. El proyecto DWT también tiene un paquete adicional que contiene un puerto de JFace y Eclipse Forms. [23]
Con JavaFX convirtiéndose en parte de la plataforma Java SE, ha habido interés en desarrollar un backend para SWT que se base en JavaFX de manera similar a SWTSwing que se basa en Swing. Un proyecto destacado que intentaba lograrlo fue SWT en JavaFX que se convirtió en parte de e (fx) clipse en 2014. [24]
Usos
Las aplicaciones (ordenadas alfabéticamente) que utilizan SWT incluyen:
- Apache Directory Studio, un navegador-editor LDAP
- BiglyBT , una bifurcación de Vuze
- Eclipse y sus complementos
- Plataforma GumTree , banco de trabajo científico
- Pajar , gerente de información
- Productos de IBM Rational Software : Rational Application Developer , Rational Software Architect , Rational Team Concert y otros.
- Productos de software IBM Lotus : Notes , Sametime , Symphony y Expeditor
- MongoChef, cliente GUI para la base de datos MongoDB
- RSSOwl , agregador de alimentos
- SmartGit, un cliente de Git , Mercurial y Apache Subversion (SVN)
- TuxGuitar , un editor de tablaturas de código abierto
- uDig , herramienta GIS
- Vuze , anteriormente llamado Azureus
Los recientes esfuerzos de código abierto en la comunidad de eclipse han llevado a la migración de SWT (y JFace) a un conjunto de herramientas de widgets apropiado para la web. El resultado ha sido Eclipse Remote Application Platform (RAP), que combina la biblioteca qooxdoo Ajax con la API SWT. Al igual que otros proyectos Java Ajax (como Echo 2, Vaadin y Google Web Toolkit ), el uso de la API SWT permite desarrollar aplicaciones rápidamente para la web de la misma manera que para el escritorio.
Ver también
- Lista de kits de herramientas de widgets
- Eclipse JFace , un conjunto de útiles widgets complejos que se basan en SWT
- Eclipse Nebula que proporciona algunos widgets adicionales basados en SWT
- OPAL algunos widgets adicionales basados en SWT
- Glimmer y Glimmer DSL para SWT , que ofrecen un lenguaje específico de dominio incrustado Ruby declarativo ligero para SWT, así como andamios, empaquetado ejecutable nativo, enlace de datos y widgets personalizados.
Notas
- ^ Iniciativa de código abierto . "Licencias por nombre" . Consultado el 24 de marzo de 2007 .
- ^ "Preguntas frecuentes: ¿Por qué Eclipse usa SWT?" . Consultado el 24 de marzo de 2007 .
- ^ Steve Northover. "SWT: Estrategia de implementación para nativos de Java" . Consultado el 22 de marzo de 2001 .
- ^ Carolyn MacLeod y Steve Northover. "SWT: Gestión de recursos del sistema operativo" . Consultado el 27 de noviembre de 2001 .
- ^ "Preguntas frecuentes: ¿SWT es mejor que Swing?" . Consultado el 16 de febrero de 2008 .
- ^ Ben Galbraith. "Introducción a SWT" . Consultado el 24 de marzo de 2007 .
- ^ a b Ella Morton. "Preguntas y respuestas de James Gosling" . Archivado desde el original el 30 de agosto de 2006 . Consultado el 24 de marzo de 2007 .
- ^ a b "Puntos de referencia de rendimiento de nueve idiomas" . Consultado el 24 de marzo de 2007 .
- ^ a b c Marinilli, Mauro. "Swing y SWT: una historia de dos bibliotecas GUI de Java" . Consultado el 7 de noviembre de 2006 .
- ^ "Preguntas frecuentes ¿Qué es SWT?" . Eclipsepedia . eclipse.org . Consultado el 16 de octubre de 2009 .
- ^ "4.8M6 - Descargas del proyecto Eclipse" . download.eclipse.org . Consultado el 1 de mayo de 2018 .
- ^ "Plataforma UI / Pruebas - Eclipsepedia" . wiki.eclipse.org . Consultado el 1 de mayo de 2018 .
- ^ http://download.eclipse.org/eclipse/downloads/drops4/R-4.7.3a-201803300640/
- ^ "4.6.3 - Descargas del proyecto Eclipse" . archive.eclipse.org . Consultado el 1 de mayo de 2018 .
- ^ Akan, Ozgur (19 de noviembre de 2004). "Por qué elijo SWT contra Swing" . Archivado desde el original el 31 de diciembre de 2006 . Consultado el 7 de noviembre de 2006 .
- ^ "Rendimiento Swing vs SWT - Eche un vistazo a las pilas de llamadas" . Javalobby.org. 2006-03-03 . Consultado el 16 de octubre de 2009 ..
- ^ Igor, Križnar (10 de mayo de 2005). "Comparación de rendimiento SWT Vs. Swing" (PDF) . cosylab.com. Archivado desde el original (PDF) el 4 de julio de 2008 . Consultado el 24 de mayo de 2008 .
Es difícil dar una regla empírica en la que SWT supere al swing, o viceversa. En algunos entornos (por ejemplo, Windows), SWT es un ganador. En otros (Linux, VMware con Windows), Swing y su optimización de redibujado superan significativamente a SWT. Las diferencias en el desempeño son significativas: los factores de 2 y más son comunes, en cualquier dirección.
. - ^ a b "Creación de sus propios widgets usando SWT" . eclipse.org. 2007-03-22 . Consultado el 13 de diciembre de 2008 .
La subclasificación puede causar errores a nivel del sistema y corre el riesgo de filtrar recursos (...) Subclasificar Canvas o Composite es la mejor manera de asegurarse de que su widget funcione en todas las plataformas SWT (...) Al subclasificar cualquier cosa que no sea Composite o Canvas debe anular el método protected void checkSubclass () para no hacer nada
- ^ La guía de desarrolladores de Java para Eclipse, 2ª ed., P359
- ^ "SwingWT - La API Swing / AWT sobre la biblioteca SWT" . Swingwt.sourceforge.net . Consultado el 16 de octubre de 2009 .
- ^ "El proyecto SWTSwing" . Swtswing.sourceforge.net . Consultado el 16 de octubre de 2009 .
- ^ "DWT - Puerto de SWT y amigos al lenguaje de programación D" . Dsource.org . Consultado el 16 de octubre de 2009 .
- ^ "Formas de Eclipse" . Eclipse.org. 2005-01-16 . Consultado el 16 de octubre de 2009 .
- ^ "SWT en JavaFX ahora forma parte de e (fx) clipse" .
Referencias
- Northover, Steve; Wilson, Mike (8 de julio de 2004). SWT: Kit de herramientas de widgets estándar, Volumen 1 . Addison-Wesley . pag. 592. ISBN 0-321-25663-8.
- Warner, Rob; Harris, Robert L. (21 de junio de 2004). La guía definitiva de SWT y JFace . Presione . pag. 684. ISBN 1-59059-325-1. Archivado desde el original el 5 de diciembre de 2010.
- Clayberg, Eric; Rubel, Dan (1 de abril de 2006). Eclipse: Creación de un complemento de calidad comercial (2ª ed.). Addison-Wesley Professional . pag. 864 . ISBN 0-321-42672-X.
- Gamma, Erich; Beck, Kent (30 de octubre de 2003). Contribuyendo a Eclipse . Addison-Wesley . pag. 416 . ISBN 0-321-20575-8.
- D'Anjou, Jim; Fairbrother, Scott; Kehn, Dan; McCarthy, Pat; Kellerman, John (5 de noviembre de 2004). The Java Developers Guide to Eclipse (2ª ed.). Addison-Wesley . pag. 1136. ISBN 0-321-30502-7.
- Matthew Scarpino, Stephen Holder, Stanford Ng y Laurent Mihalkovic (28 de noviembre de 2004). SWT / JFace en acción . Manning . pag. 496. ISBN 1-932394-27-3.CS1 maint: varios nombres: lista de autores ( enlace )
enlaces externos
- Página web oficial