Libgweather, la pequeña biblioteca de GNOME que consulta los servicios de clima está tiene una versión principal nueva para permitir que las aplicaciones lo usen para ser portado a GTK4 .
Al principio , había un subprograma meteorológico en el panel de GNOME.
Tenía un montón de código que hurgaba en un par de sitios web para obtener la información meteorológica para un aeropuerto determinado o una observación meteorológica estaciones, y se envía con una lista de código de las ubicaciones METEAR más cercanas.
En 2007, el código pertinente se trasladó a su propio repositorio , de modo que otras aplicaciones y el sistema la configuración podría reutilizar el mismo código que el subprograma del panel: así nació la biblioteca libgweather.
Aparte de la información meteorológica básica y la ubicación de objetos, libgweather también tenía un par de widgets: uno para seleccionar de una ubicación (con autocompletado) y un para seleccionar una zona horaria usando la ubicación.
Dado que libgweather seguía siendo una biblioteca ad hoc para un puñado de aplicaciones, no hubo una explícita API que garantizase estabilidad; de hecho, para poder utilizarla, tenía que “participar” con un específico Símbolo del preprocesador C.
Pasó el tiempo y aparecieron algunas aplicaciones más durante la version inicial de GNOME 3. Como Clima, seguido de Reloj meses después.
La mayoría de los consumidores de libgweather en realidad iban a través de un enlace de idioma, lo que significaba que en realidad no estaban “optando por” la API a través del símbolo de preprocesador explícito; también significó que los cambios en la API podrían terminar encontrando el objeto solo después de un llamado a libgweather, pero no en el ciclo de desarrollo.
Así, los consumidores de GWeather eran pocos y distantes entre sí, y el API no se estabilizó.
Avance rápido hasta ahora
Las principales de aplicaciones de GNOME que utilizan GWeather están en proceso de ser portado a GTK4 , pero GWeather todavía se envía con dos widgets GTK3 .
Dado que no puede tener los tipos GTK3 y GTK4 en el mismo proceso, esto requiere que ya sea portando GWeather a GTK4.
Como resulta, los widgets no se comparten realmente entre aplicaciones que usan libgweather, y todos ellos también han sido rediseñados o están usando el libadwaita/GTK4 como una oportunidad para refrescar su apariencia general.
Para GNOME 42, el plan para libgweather es:
- Nueva API para la versión de a 4.0 que garantice la instalación en paralelo con el antiguo libgweather-3; esto requiere cambiar el nombre de cosas como el archivo pkg-config archivo y el esquema de configuración, junto con la biblioteca compartida
- Eliminar los widgets GTK y alguna antigua API que no ha estado funcionando en años, como obtener la animación de la imagen del radar
- Estabilizar la API y convertir libgweather en una biblioteca adecuada, con la habituales garantías de API en su estabilidad (depreciaciones y nuevos símbolos agregados solo durante los ciclos de desarrollo, sin cambios/eliminaciones hasta la siguiente versión importante de la API )
- Facilitar el uso de objetos libgweather con
GListModelbasada en API - Documentar la API correctamente
- Limpiar los aspectos internos de varios años de prácticas y estilos de codificación inconsistentes.
Mientras tanto, la antigua API libgweather-3 será congelará, para las herramientas que todavía lo usan y que no se trasladarán a en el GTK4 en el corto plazo.