GTK4 cambia la mentalidad de listas con GListModel y GListStore
La serie sobre widgets de GTK explica por qué el bucle de creación manual de filas es un callejón sin salida y cómo el patrón modelo-vista lo resuelve.
El desarrollo de interfaces en GTK4 ha cambiado la forma en que se manejan las listas de datos. Ya no se trata de construir etiquetas y añadir filas manualmente al árbol de widgets, sino de separar completamente el estado de los datos de la representación visual. Esta es la tercera entrega de una guía de campo sobre GTK Widgets, centrada en el cambio de mentalidad necesario para dominar GListModel y GListStore.
Durante años, la práctica estándar en cualquier toolkit de interfaz gráfica fue iterar sobre el conjunto de datos, crear una etiqueta o fila para cada elemento y añadirlo al contenedor. En GTK2 y GTK3, este problema lo resolvían mecanismos como GtkTreeView y GtkListStore, un aparato complejo de celdas y renderizadores que hoy está en gran parte deprecado. Este enfoque funciona para listas estáticas, pero se rompe en cuanto el dato es dinámico: si una tarea se marca como completada, se filtra el listado o se reordena, el desarrollador debe encontrar, eliminar, reconstruir y volver a insertar la fila correcta en el índice adecuado. Este código manual es propenso a errores sutiles que pasan las pruebas iniciales pero fallan en producción semanas después.
La solución moderna en GTK4 invierte la responsabilidad. GListModel es una interfaz que cualquier objeto GObject puede implementar para declarar que es una colección ordenada e indexable que notifica sus cambios. GListStore es la implementación concreta y mutable que aloja los datos en memoria. La clave es que la vista observa este modelo; nunca se manipula el widget directamente para actualizar contenido.
En el ecosistema de Rust, esto implica una particularidad técnica: GListStore solo acepta objetos GObject. Un struct de Rust plano no puede insertarse directamente. Para datos simples, la solución recomendada es glib::BoxedAnyObject, que envuelve cualquier valor de Rust como un GObject sin necesidad de subclasear, a cambio de verificar los préstamos en tiempo de ejecución en lugar de en tiempo de compilación. Si la interfaz necesita observar cambios en propiedades específicas, entonces sí se requiere una subclase real de GObject.
Para mostrar los datos en pantalla, GtkListView requiere dos componentes adicionales: un modelo de selección (como NoSelection si no se permite seleccionar filas) y una fábrica (SignalListItemFactory). La fábrica define la receta para convertir un objeto de datos en una fila de interfaz. Este patrón permite que los archivos de código reflejen la separación de preocupaciones: un archivo para los datos, otro para la definición de la fila y un tercero para la conexión con la ventana.
Este cambio de paradigma es crucial para cualquier desarrollador que migre de widgets antiguos o que aspire a construir aplicaciones de escritorio modernas en GNOME. La documentación de referencia a menudo no destaca esta transición mental, pero es fundamental para evitar el mantenimiento de código de interfaz frágil. La separación estricta entre datos y vista no es solo una buena práctica, sino la base arquitectónica de las listas modernas en GTK4.
