El Standard Widget Toolkit ( SWT ) es un conjunto de herramientas de widgets gráficos para su uso con la plataforma Java . Fue desarrollado originalmente por Stephen Northover en IBM y ahora lo mantiene Eclipse Foundation junto con Eclipse IDE . Es una alternativa a los conjuntos de herramientas de interfaz gráfica de usuario (GUI) Java Abstract Window Toolkit (AWT) y Swing proporcionados por Sun Microsystems como parte de la plataforma Java, edición estándar (J2SE).
Para mostrar los elementos de la GUI, la implementación de SWT accede a las bibliotecas de GUI nativas del sistema operativo mediante la interfaz nativa de Java (JNI) de una manera similar a la de los programas escritos mediante interfaces de programación de aplicaciones (API) específicas del sistema operativo. Los programas que invocan SWT son portables, pero la implementación del conjunto de herramientas, a pesar de que parte de ella está escrita 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 conjunto de herramientas de interfaz gráfica de usuario de Java fue el 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 biblioteca contenedora de Java simple alrededor de 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 completo de componentes de software de GUI que AWT. Los elementos de GUI de Swing son completamente Java sin código nativo: en lugar de encapsular componentes de GUI nativos, Swing dibuja sus propios componentes utilizando Java 2D para llamar a rutinas de dibujo de bajo nivel del sistema operativo.
Las raíces de SWT se remontan al trabajo que Object Technology International (OTI) realizó en la década de 1990 cuando creó 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 mismo tiempo que proporcionaba 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 kit de herramientas que tuviera " apariencia nativa " y " rendimiento nativo ", crearon SWT como reemplazo de Swing. [2]
Diseño

SWT es un contenedor de objetos de código nativo, como objetos GTK , objetos Motif , etc. Por este motivo, los widgets SWT suelen denominarse [ ¿quién lo dice? ] "peso pesado", lo que evoca imágenes de un contenedor Java ligero alrededor de un objeto nativo "pesado". En los casos en los que las bibliotecas de GUI de la plataforma nativa no admiten la funcionalidad requerida para SWT, SWT implementa su propio código de GUI en Java, de forma similar a Swing. En esencia, SWT es un compromiso entre el rendimiento y la apariencia de bajo nivel 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 objetivos diferentes. El propósito de SWT es proporcionar una API común para acceder a widgets nativos en un espectro de plataformas. Los objetivos principales del diseño son un alto rendimiento, una apariencia nativa y una integración profunda de la plataforma. Swing, por otro lado, está diseñado para permitir una apariencia altamente personalizable que sea común en todas las plataformas". [5]
Se ha argumentado [ ¿quién? ] que SWT presenta un diseño limpio, inspirado en parte por Erich Gamma, famoso por sus patrones de diseño . [6]
SWT es un conjunto de herramientas más simple que Swing, con menos funcionalidades (posiblemente) extrañas para el desarrollador promedio. [7] Esto ha llevado a algunas personas [ ¿quiénes? ] a 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 portar a nuevas plataformas por la misma razón que AWT alguna vez tuvo problemas de portabilidad: que es demasiado simple, de muy bajo nivel y demasiado ligado a la API GUI de Win32, lo que genera problemas para adaptar la API de SWT a otros conjuntos de herramientas GUI, como Motif y OS X Carbon. [7]
Aunque SWT no implementa la arquitectura popular modelo-vista-controlador (MVC) utilizada en Swing y muchos otros conjuntos de herramientas de GUI de alto nivel, la biblioteca JFace , que se desarrolla como parte del mismo proyecto Eclipse, proporciona una abstracción MVC multiplataforma de alto nivel 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 el mismo aspecto 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 perceptible. Por ejemplo, el widget de árbol de macOS presenta una animación sutil cuando se expande un árbol y los botones predeterminados tienen un brillo pulsante animado para centrar la atención del usuario en ellos. La versión Swing predeterminada de estos widgets no tiene animación.
Dado que SWT es simplemente un contenedor alrededor del código GUI nativo, no requiere una gran cantidad de actualizaciones cuando se modifica dicho código nativo, siempre que los proveedores de sistemas operativos tengan cuidado de no interrumpir 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 "apariencias conectables". Estas permiten emular la interfaz de usuario de la plataforma nativa mediante temas , que deben actualizarse para reflejar los cambios en la GUI del sistema operativo, como temas u otras actualizaciones de apariencia.
SWT apunta a una "integración profunda de la plataforma", la referencia de Eclipse al uso de widgets nativos por parte de SWT. Según Mauro Marinillia de developer.com, "siempre que se necesite una integración estrecha con la plataforma nativa, SWT puede ser una ventaja". [9] Esta integración profunda puede ser útil de varias maneras, por ejemplo, al permitir que SWT envuelva objetos ActiveX en Microsoft Windows .
Programación

El siguiente es un programa básico de "¡Hola mundo!" que utiliza SWT. Muestra una ventana ( Shell ) y una etiqueta.
importar org.eclipse.swt.* ; importar org.eclipse.swt.widgets.* ;
clase pública HolaMundo { public static void main ( String [] args ) { Pantalla pantalla = new Pantalla (); Shell shell = new Shell ( pantalla ); Etiqueta etiqueta = new Etiqueta ( shell , SWT . NONE ); etiqueta . setText ( "¡Hola, mundo!" ); etiqueta . pack (); shell . pack (); shell . open (); while ( ! shell . isDisposed ()) { if ( ! display . readAndDispatch ()) pantalla . sleep (); } pantalla . dispose (); } }
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 utilizan.
Soporte de plataforma

SWT debe ser portado 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 es 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 utiliza 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 SWT es técnicamente solo una capa sobre la funcionalidad de interfaz gráfica de usuario proporcionada por la biblioteca nativa, por lo que exponer al programador al código de interfaz gráfica de usuario 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 la API de interfaz de usuario más delgada posible que se pueda implementar de manera uniforme en el conjunto más grande posible de plataformas y, al mismo tiempo, brindar la funcionalidad suficiente para crear aplicaciones ricas con interfaz gráfica de usuario (GUI)". [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]
- Ventanas : [12]
- Win32
- Windows Presentation Foundation (WPF), en desarrollo
- Similares a Unix : Linux , FreeBSD :
- macOS :
A partir de 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, al igual que Linux en 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 GUI de alto rendimiento ; más rápido, con mayor capacidad de respuesta y con menor uso de recursos del sistema que Swing. [15]
Se han hecho 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 evaluadas 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 exhaustivo de evaluaciones comparativas concluyó que ni Swing ni SWT superaron al otro en el caso general. [17]
Extensibilidad y comparación con otros códigos Java
Debido al uso de código nativo, las clases SWT no permiten una herencia sencilla para todas las clases de widgets, lo que algunos usuarios consideran que puede perjudicar la extensibilidad. [9] Esto puede hacer que la personalización de widgets existentes sea más difícil de lograr con SWT que si se usara Swing. [18] Ambos kits de herramientas admiten la escritura de nuevos widgets utilizando solo código Java, sin embargo, en SWT se necesita trabajo adicional para hacer que el nuevo widget funcione en todas las plataformas. [18]
Los widgets SWT, a diferencia de casi cualquier otro conjunto 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 . Los objetos SWT deben desasignarse explícitamente utilizando el disposemétodo , que es análogo al del lenguaje C. [19] Si esto no se hace, pueden resultar fugas de memoria u otro comportamiento no deseado. Sobre este tema, algunos han comentado que "desasignar explícitamente los recursos podría ser un paso atrás en el tiempo de desarrollo (y costos) al menos para el desarrollador Java promedio" y que "esto es una bendición mixta. Significa más control (y más complejidad) para el desarrollador SWT en lugar de más automatización (y lentitud) cuando se usa Swing". [9] La necesidad de la desasignación manual de objetos cuando se usa SWT se debe en gran medida al uso de objetos nativos de SWT. Estos objetos no son rastreados por la JVM de Java, por lo que no puede rastrear si dichos objetos están en uso o no y, por lo tanto, no puede recolectarlos en un momento adecuado.
free
Desarrollo
Se están desarrollando algunas actividades para permitir la combinación de Swing y SWT. Se están intentando dos enfoques diferentes:
- SwingWT es un proyecto que busca ofrecer una implementación alternativa de Swing. Utiliza un back end SWT para mostrar sus widgets, lo que proporciona 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 que busca proporcionar un back end de Swing para SWT. De hecho, SWT podría ejecutarse utilizando objetos nativos de Swing en lugar de, por ejemplo, objetos nativos de GTK o Windows. Esto permitiría que SWT funcione en todas las plataformas compatibles con Swing. [21]
A partir de 2006, se lanzó un puerto SWT-3.2 al 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 complementario que contiene un puerto de JFace y Eclipse Forms. [23]
Con la incorporación de JavaFX a la plataforma Java SE, ha surgido el interés por desarrollar un backend para SWT que dependa de JavaFX de forma similar a como SWTSwing depende de Swing. Un proyecto destacado que intentó lograrlo fue SWT en JavaFX, que pasó a formar 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
- Eclipse y sus complementos
- Plataforma GumTree , banco de trabajo científico
- Pajar , gestor 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
- Studio 3T, cliente GUI para la base de datos MongoDB [25]
- RSSOwl , agregador de feeds
- SmartGit, un cliente de Git , Mercurial y Apache Subversion (SVN)
- TuxGuitar , un editor de tablaturas de código abierto
- uDig , herramienta SIG
- Vuze , anteriormente llamado Azureus
Los recientes esfuerzos de código abierto en la comunidad Eclipse han llevado a una adaptación de SWT (y JFace) a un conjunto de herramientas de widgets adecuado para la web. El resultado ha sido la Plataforma de aplicaciones remotas (RAP) de Eclipse, que combina la biblioteca Ajax qooxdoo con la API de SWT. Al igual que otros proyectos de Java Ajax (como Echo 2, Vaadin y Google Web Toolkit ), el uso de la API de SWT permite desarrollar aplicaciones rápidamente para la web de la misma manera que para el escritorio.
Véase también
Notas
- ^ Iniciativa de código abierto . «Licencias por nombre» . Consultado el 24 de marzo de 2007 .
- ^ "Preguntas frecuentes: ¿Por qué Eclipse utiliza 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: Managing Operating System Resources" (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 la teoría de la contracción nerviosa" . Consultado el 24 de marzo de 2007 .
- ^ de Ella Morton. "James Gosling Q & A". Archivado desde el original el 2006-08-30 . Consultado el 2007-03-24 .
- ^ ab "Puntos de referencia de rendimiento de nueve idiomas" . Consultado el 24 de marzo de 2007 .
- ^ abc Marinilli, Mauro. "Swing y SWT: una historia de dos bibliotecas de interfaz gráfica de usuario 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 .
- ^ "Platform UI/Testing - Eclipsepedia" (Interfaz de usuario/pruebas de la plataforma) . wiki.eclipse.org . Consultado el 1 de mayo de 2018 .
- ^ "4.7.3a - Descargas del proyecto Eclipse". download.eclipse.org . Archivado desde el original el 16 de abril de 2018.
- ^ "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 en lugar de Swing". Archivado desde el original el 31 de diciembre de 2006. Consultado el 7 de noviembre de 2006 .
- ^ "Rendimiento de Swing vs. SWT: observe las pilas de llamadas". Javalobby.org. 2006-03-03. Archivado desde el original el 2017-09-17 . Consultado el 2009-10-16 ..
- ^ Igor, Križnar (10 de mayo de 2005). "Comparación de rendimiento entre SWT y 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 general en la que SWT superaría a Swing, o viceversa. En algunos entornos (por ejemplo, Windows), SWT es un ganador. En otros (Linux,
VMware
que aloja Windows), Swing y su optimización de redibujado superan significativamente a SWT. Las diferencias en el rendimiento son significativas: los factores de 2 y más son comunes, en cualquier dirección.
.
- ^ ab "Creación de sus propios widgets con SWT". eclipse.org. 22 de marzo de 2007. Consultado el 13 de diciembre de 2008.
La subclasificación puede provocar errores graves a nivel de sistema y conlleva el riesgo de pérdida de recursos. (...)La subclasificación de Canvas o Composite es la mejor forma de garantizar 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.
- ^ Guía para desarrolladores de Java sobre Eclipse, 2.ª edición, pág. 359
- ^ "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 – Adaptación de SWT y sus amigos al lenguaje de programación D". Dsource.org . Consultado el 16 de octubre de 2009 .
- ^ "Formas de eclipse". Eclipse.org. 16 de enero de 2005. Consultado el 16 de octubre de 2009 .
- ^ "SWT en JavaFX ahora es parte de e(fx)clipse". 13 de marzo de 2014.
- ^ "3T MongoChef ahora es Studio 3T". 8 de febrero de 2017.
Referencias
- Northover, Steve; Wilson, Mike (8 de julio de 2004). SWT: The Standard Widget Toolkit, Volumen 1. Addison-Wesley . p. 592. ISBN 0-321-25663-8.
- Warner, Rob; Harris, Robert L. (21 de junio de 2004). La guía definitiva de SWT y JFace. Apress . p. 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: Building commercial-quality plug-in (2.ª ed.). Addison-Wesley Professional . p. 864. ISBN 0-321-42672-X.
- Gamma, Erich; Beck, Kent (30 de octubre de 2003). Contribución a Eclipse. Addison-Wesley . pág. 416. ISBN 0-321-20575-8.
- D'Anjou, Jim; Fairbrother, Scott; Kehn, Dan; McCarthy, Pat; Kellerman, John (5 de noviembre de 2004). Guía de Eclipse para desarrolladores de Java (2.ª edición). Addison-Wesley . p. 1136. ISBN 0-321-30502-7.
- Matthew Scarpino, Stephen Holder, Stanford Ng y Laurent Mihalkovic (28 de noviembre de 2004). SWT/JFace in Action . Manning . Pág. 496. ISBN. 1-932394-27-3.
{{cite book}}: CS1 maint: multiple names: authors list (link)
Enlaces externos
- Sitio web oficial