stringtranslate.com

Kit de herramientas de ventana abstracta

Formulario de Windows con algunos ejemplos de AWT

El Abstract Window Toolkit ( AWT ) es el kit de herramientas de widgets de interfaz de usuario , gráficos y ventanas dependientes de la plataforma original de Java , anterior a Swing . El AWT es parte de Java Foundation Classes (JFC), la API estándar para proporcionar una interfaz gráfica de usuario (GUI) para un programa Java. AWT es también el conjunto de herramientas GUI para varios perfiles de Java ME . Por ejemplo, los perfiles de configuración de dispositivos conectados requieren tiempos de ejecución de Java en teléfonos móviles para admitir Abstract Window Toolkit.

Historia

Cuando Sun Microsystems lanzó Java por primera vez en 1995, los widgets AWT proporcionaron un nivel reducido de abstracción sobre la interfaz de usuario nativa subyacente. Por ejemplo, crear una casilla de verificación AWT haría que AWT llamara directamente a la subrutina nativa subyacente que creó una casilla de verificación. Sin embargo, la casilla de verificación en Windows no es la misma que la casilla de verificación en macOS o en los distintos tipos de Unix . Algunos desarrolladores de aplicaciones prefieren este modelo porque proporciona un alto grado de fidelidad al conjunto de herramientas de ventanas nativas subyacente y una integración perfecta con las aplicaciones nativas. En otras palabras, un programa GUI escrito usando AWT parece una aplicación nativa de Microsoft Windows cuando se ejecuta en Windows, pero el mismo programa parece una aplicación nativa de Apple Macintosh cuando se ejecuta en una Mac, etc. Sin embargo, a algunos desarrolladores de aplicaciones no les gusta este modelo porque prefieren que sus aplicaciones se vean exactamente iguales en todas las plataformas.

En J2SE 1.2 , el kit de herramientas Swing reemplazó en gran medida a los widgets de AWT. Además de proporcionar un conjunto más rico de widgets de interfaz de usuario, Swing dibuja sus propios widgets (utilizando Java 2D para llamar a subrutinas de bajo nivel en el subsistema de gráficos local) en lugar de depender del módulo de interfaz de usuario de alto nivel del sistema operativo. Swing ofrece la opción de utilizar la "apariencia" de la plataforma nativa o una apariencia multiplataforma (la "apariencia de Java") que se ve igual en todos los sistemas de ventanas.

Arquitectura

El AWT proporciona dos niveles de API :

AWT también pone a disposición de las aplicaciones algunas funciones de nivel superior, como por ejemplo:

Ni AWT ni Swing son inherentemente seguros para subprocesos . Por lo tanto, el código que actualiza la GUI o procesa eventos debe ejecutarse en el subproceso de distribución de eventos . De lo contrario, se puede producir un punto muerto o una condición de carrera. Para solucionar este problema, una clase de utilidad llamada SwingWorker permite que las aplicaciones realicen tareas que requieren mucho tiempo después de eventos de interacción del usuario en el hilo de distribución de eventos.

Mezclando componentes AWT y Swing

Cuando haya una versión Swing de un componente AWT, comenzará con J- y deberá usarse exclusivamente, reemplazando la versión AWT. Por ejemplo, en Swing, use solo JButton, nunca la clase Button. Como se mencionó anteriormente, las clases principales de AWT, como Color y Fuente, todavía se usan tal como están en Swing.

Al dibujar en Swing, use JPanel y anule paintComponent(Graphics g) en lugar de usar los métodos AWT paint().

Antes de Java 6 Update 12 , mezclar componentes Swing y widgets AWT básicos a menudo resultaba en efectos secundarios no deseados, con widgets AWT apareciendo encima de los widgets Swing independientemente de su orden z definido . Este problema se debió a que la arquitectura de renderizado de los dos kits de herramientas de widgets era muy diferente, a pesar de que Swing tomó prestados contenedores superiores pesados ​​de AWT. [1]

A partir de Java 6 Update 12 , es posible mezclar widgets Swing y AWT sin tener problemas de orden z. [2]

Ejemplo

importar java.awt.* ; importar java.awt.event.WindowAdapter ; importar java.awt.event.WindowEvent ;   clase pública MiAplicación {    public static void main ( char [] args ) { Marco marco = nuevo Marco ( "Aplicación" ); marco . agregar ( nueva etiqueta ( "¡Hola!" )); marco . establecerTamaño ( 500 , 500 ); marco . setLocationRelativeTo ( nulo ); //Centra el marco de la ventana . addWindowListener ( new WindowAdapter () { @Override public void windowClosing ( WindowEvent e ) { frame . dispose (); // Libera recursos de pantalla nativos } }); marco . setVisible ( verdadero ); } }                                  

Implementación

Como el AWT es un puente hacia la interfaz de usuario nativa subyacente, su implementación en un nuevo sistema operativo puede implicar mucho trabajo, especialmente si involucra alguno de los widgets GUI del AWT, porque cada uno de ellos requiere que se desarrollen sus pares nativos. desde cero.

Se ha creado un nuevo proyecto, Caciocavallo, que proporciona una API Java basada en OpenJDK para facilitar la implementación de AWT en nuevos sistemas. [3] [4] El proyecto ha implementado con éxito widgets AWT utilizando Java2D . [5] Desde entonces, todas las modificaciones necesarias del núcleo JDK se han enviado a OpenJDK 7 , [6] lo que significa que Java ahora se puede usar en una pila de gráficos distinta a la proporcionada por el JDK oficial ( X Window System , OpenGL o DirectX ), al incluir una biblioteca externa y configurar algunas propiedades del sistema. Se está desarrollando un backend DirectFB para Caciocavallo [7] , al igual que un backend HTML5 ; el objetivo es implementar aplicaciones Swing existentes (sin soporte de Java) como aplicaciones web ordinarias que se ejecutan en un servidor web. [7] [8]

Ver también

Referencias

  1. ^ Fowler, Amy (1994). "Mezcla de componentes pesados ​​y ligeros". Microsistemas solares . Archivado desde el original el 23 de diciembre de 2011 . Consultado el 17 de diciembre de 2008 .
  2. ^ "Error/RFE solucionado en la compilación actual de JDK 6u12". Microsistemas solares . 12 de diciembre de 2008. Archivado desde el original el 17 de diciembre de 2008 . Consultado el 17 de diciembre de 2008 .
  3. ^ Torre, Mario (2 de marzo de 2008). "PROPUESTA FINAL: Backends GUI portátiles". Archivado desde el original el 19 de marzo de 2012 . Consultado el 7 de septiembre de 2008 .
  4. ^ Kennke, Roman (18 de diciembre de 2008). "Descripción general de la arquitectura de Caciocavallo" . Consultado el 7 de septiembre de 2008 .
  5. ^ Kennke, Roman (3 de septiembre de 2008). "Compañeros de Cacio Swing AWT". Archivado desde el original el 13 de marzo de 2012 . Consultado el 7 de septiembre de 2008 .
  6. ^ "¿Cuánto se ha impulsado río arriba?". openjdk.java.net. 20 de septiembre de 2009. Archivado desde el original el 19 de marzo de 2012 . Consultado el 7 de marzo de 2010 . No necesita más de esos parches, con la última actualización de FontManager, ahora todo está en funcionamiento, así que use el repositorio de Cacio, es completamente autónomo.
  7. ^ ab Kennke, Roman (28 de julio de 2011). «JDK7 y la frescura de Cacio» . Consultado el 8 de agosto de 2011 .
  8. ^ Eisserer, Clemens. "Backend HTML5/Canvas para Caciocavallo (GNU-Classpath)". Archivado desde el original el 21 de marzo de 2012 . Consultado el 8 de agosto de 2011 .

enlaces externos