El proyecto GNOME ha publicado la versión 1.5 de la biblioteca Libadwaita, que incluye un conjunto de componentes para el diseño de la interfaz de usuario, de acuerdo con las recomendaciones de las GNOME HIG (Guías de Interfaz Humana). La biblioteca contiene widgets y objetos listos para construir aplicaciones que se alineen con el estilo general de GNOME, cuya interfaz puede adaptarse dinámicamente a pantallas de cualquier tamaño. El código de la biblioteca está escrito en C y se distribuye bajo la licencia LGPL 2.1+.
La biblioteca libadwaita se utiliza junto con GTK4 e incluye los componentes del tema Adwaita usado en GNOME, que se han extraído de GTK en una biblioteca separada. Extraer los elementos visuales de GNOME en una biblioteca independiente permite desarrollar los cambios necesarios para GNOME por separado de GTK, lo que permite a los desarrolladores de GTK centrarse en lo fundamental, mientras que los desarrolladores de GNOME pueden implementar los cambios de diseño necesarios de manera más rápida y flexible, sin afectar a GTK mismo.
La biblioteca incluye widgets estándar que abarcan diversos elementos de la interfaz, como listas, paneles, bloques de edición, botones, pestañas, formularios de búsqueda, cuadros de diálogo, etc. Los widgets propuestos permiten crear interfaces universales que funcionan orgánicamente tanto en pantallas grandes de PCs y laptops como en pequeñas pantallas táctiles de teléfonos inteligentes. La interfaz de las aplicaciones cambia dinámicamente en función del tamaño de la pantalla y de los dispositivos de entrada disponibles. La biblioteca también incluye un conjunto de estilos Adwaita, que ajustan la apariencia de acuerdo con las recomendaciones de GNOME, sin necesidad de realizar una adaptación manual.
El cambio principal en libadwaita 1.5 fue la reestructuración de los widgets adaptativos para la creación de diálogos que se ajustan al tamaño del área visible. A diferencia de los diálogos tradicionales, que se ubican en ventanas separadas, los nuevos diálogos se crean del lado del cliente, se renderizan dentro de las ventanas existentes y no pueden salir del límite de la ventana principal. Este enfoque simplifica la creación de diálogos universales, que se combinan con interfaces para sistemas móviles y de escritorio, y proporciona más opciones para gestionar los diálogos (por ejemplo, no se necesita rastrear el desbordamiento de la ventana, se puede elegir el comportamiento respecto a los botones de cierre, se garantiza la expansión automática a pantalla completa en versiones móviles de aplicaciones, y se considera el estilo de la ventana actual, no del sistema, al oscurecer el diálogo).
En el futuro, se planea implementar otra variante de diálogos similares, vinculados no a ventanas, sino a pestañas dentro de una ventana, lo que puede ser útil en aplicaciones como navegadores para que los diálogos asociados a la pestaña no cubran la ventana principal al cambiar entre pestañas.
Para dispositivos móviles, se ha implementado la capacidad de colocar diálogos en forma de hojas fijas en la parte inferior de la pantalla (bottom sheets), en lugar de en forma de hojas centradas. Los diálogos anclados en la parte inferior evitan que los usuarios se confundan al cerrar ventanas — en estos diálogos, parte de la ventana principal permanece visible y los botones de cierre de la ventana principal y del diálogo están claramente separados, por lo que ahora es difícil confundirlos.
La gestión de los nuevos diálogos se lleva a cabo mediante la clase AdwDialog, cuya utilización en la mayoría de las situaciones se asemeja a la de la clase GtkWindow, y las diferencias se limitan a las operaciones de visualización y cierre. Por ejemplo, la propiedad «:transient-for» se ha reemplazado por un parámetro en la función adw_dialog_present(), se ha añadido una nueva señal «::close-attempt», y se ha modificado el manejo del parámetro «:can-close». En lugar de las clases AdwPreferencesWindow, AdwAboutWindow y AdwMessageDialog, se propone usar las clases AdwPreferencesDialog, AdwAboutDialog y AdwAlertDialog con los nuevos diálogos.
Los diálogos que no tienen una ventana principal seguirán siendo tratados como ventanas separadas. Al igual que las ventanas, también funcionarán diálogos cuyas ventanas principales no se pueden utilizar para alojar diálogos, por ejemplo, si no permiten el cambio de tamaño o si carecen de las clases AdwWindow y AdwApplicationWindow.
Cambios no relacionados con la reingeniería de diálogos en Libadwaita 1.5:
- Se ha añadido la propiedad «:text-length» a la clase AdwEntryRow para limitar el tamaño del texto en el campo de entrada.
- Se ha añadido el método remove_response() a la clase AdwMessageDialog.
- A la clase AdwBreakpointBin, que permite modificar la interfaz de usuario de manera arbitraria según el tamaño de la ventana, se le ha añadido la posibilidad de eliminar puntos de ruptura de forma programática.
- Se ha añadido la bandera «:allow-window-handle» a la clase AdwSwipeTracker, que permite el desplazamiento sobre la barra superior (se utiliza en las vistas ancladas al borde inferior).
- Se ha incrementado el brillo de los colores utilizados para oscurecer ventanas en el estilo de tema oscuro.
Fuente: opennet.ru
