Diseño e implementación de una arquitectura modular para la modernización y unificación de extensiones en GNOME Shell 50

0. Resumen de Componentes

• Aylur’s Widgets (base conceptual)
  • Background Clock
  • Battery Bar
  • Media Player (Top Bar)
    • Referencias: Media Controls, Advanced Media Controller, Dock Media Player
  • Workspace Indicator
    • Inspiración: Space Bar
  • Notification Indicator
  • Power Menu
• Quick Text
  • Restauración de compatibilidad con GNOME 50
• Quick Settings Tweaks (integración parcial)
  • Media Widget (alternativa al Top Bar)
  • Notification Widget
  • Weather Widget
  • Reordenamiento de Quick Settings
  • Configuración avanzada del Date Menu
    • Referencia: Date Menu Formatter
• Panel Corners
  • Inspiración directa: Panel Corners (aunetx)

1. Planteamiento del problema

El presente proyecto aborda la modernización y unificación de múltiples extensiones legacy del entorno de escritorio GNOME mediante el diseño de una arquitectura modular compatible con GNOME Shell 50.

El problema central radica en la fragilidad estructural del ecosistema de extensiones, el cual depende de APIs internas sujetas a cambios frecuentes, lo que genera obsolescencia. Se propone el desarrollo de una extensión unificada que sea: estrictamente modular, con bajo acoplamiento, que gestione de forma centralizada las señales, “lazy loading” y con control explícito del ciclo de vida de cada componente.

El resultado esperado es una arquitectura extensible, modular, mantenible y optimizada, validada mediante métricas objetivas de rendimiento y estabilidad.

2. Objetivos

2.1 Objetivo general

Diseñar, implementar y mantener una extensión modular para GNOME 50 que reinterprete y modernice los componentes de Aylur’s Widgets, mediante una arquitectura desacoplada, eficiente y mantenible, adaptada a los cambios de API de GNOME Shell y GJS.

La propuesta no consiste en replicar la extensión original, sino en:

• Evaluar la vigencia funcional de cada componente en GNOME 50.
• Determinar cuáles han sido reemplazados por mejoras nativas del entorno de escritorio.
• Rediseñar los módulos bajo principios de modularidad estricta.
• Optimizar el rendimiento y evitar degradación en animaciones del Shell.
• Consolidar un backend reutilizable y extensible.

Repositorio original: Código fuente de Aylur’s Widgets

2.2 Objetivos específicos

1. Separar estrictamente la lógica de negocio y la capa de presentación (UI).
2. Implementar un sistema centralizado de gestión de señales.
3. Diseñar e implementar un framework modular interno.
4. Implementar lazy loading de módulos.
5. Validar consumo de CPU y memoria mediante profiling.
6. Documentar formalmente la arquitectura interna y contratos entre módulos.
7. Garantizar compatibilidad total con GNOME 50.
8. Minimizar conflictos con extensiones populares.
9. Diseñar un backend MPRIS unificado reutilizable.
10. Reducir listeners globales innecesarios y evitar memory leaks.

2.3 componentes a reinterpretar y adaptar.

2.3.1 Módulos prioritarios

Background Clock

Widget de reloj superpuesto en el escritorio, similar al comportamiento de conky.

Funcionalidades:

• Posicionamiento mediante layouts o coordenadas.
• Personalización de tipografía, color, tamaño y sombras.
• Configuración del contenedor (background, padding, bordes, redondeado).

Problema detectado: Degradación de rendimiento al ingresar al Overview.

Objetivos técnicos:

• Analizar conflictos con extensiones como DING (Desktop Icons NG).
• Optimizar renderizado evitando bloqueos en animaciones.
• Minimizar impacto en composición gráfica.

Battery Bar

Indicador alternativo de batería en el Top Bar.

Configuraciones:

• Posición (izquierda, centro, derecha).
• Visibilidad de ícono y porcentaje.
• Dimensiones.
• Colores dinámicos configurables (normal, cargando, batería baja).

Justificación: Módulo de baja complejidad técnica y alto impacto visual. Ideal como implementación temprana (MVP).

Media Player

Controles multimedia integrados en el Top Bar:

• Información de pista.
• Controles (anterior, pausa, siguiente).
• Widget desplegable configurable.
• Gestión de caché.
• Selección de reproductor preferido.
• Configuración visual avanzada.

Referencias comparativas:

• Media Controls
• Advanced Media Controller
• Dock Media Player

Objetivos técnicos:

• Evitar duplicidad entre el reproductor del Top Bar, del panel de notificaciones y del Quick Settings.
• Separar estrictamente estado y representación visual.

Workspace Indicator

Indicador configurable de espacios de trabajo.

Referencia: Space Bar

Objetivos:

• Ofrecer alternativa más configurable que la píldora nativa.
• Incorporar atajos estilo tiling window manager.
• Añadir animaciones personalizadas optimizadas.

Notification Indicator

Indicador de notificaciones con contador numérico.

Configuraciones:

• Posición.
• Offset.
• Estilo (íconos o contador).
• Máximo de íconos.
• Visibilidad del contador.

Justificación: GNOME incluye indicador visual pero no contador cuantitativo.

Power Menu

Botón personalizable con diálogo de apagado.

Configuraciones:

• Posición.
• Layout (2x2 o 1x4).
• Tamaño y redondez.
• Padding y espaciado.
• Fondo del diálogo.

Módulo de baja complejidad y buena aceptación estética.

2.3.2 Módulos Secundarios o Parcialmente Descartados

Dashboard

Agrupa widgets en una ventana accesible desde el Top Bar o con atajo de teclado.

Evaluación: Potecialmentecialmente redundante. Se considera opcional o simplificado.

QuickSettings y DateMenu Mod

Permiten modificar Quick Settings y Date Menu.

Decisión:

• Descartar modificaciones invasivas.
• Evaluar componentes reutilizables.

Referencia: Date Menu Formatter

Partes rescatables:

• Monitor de recursos.
• Formato configurable de fecha y hora.

2.3.3 Extensiones Adicionales a Integrar

Quick Text

Extensión compatible hasta GNOME 47. Repositorio: Quick Text

Objetivos:

• Restaurar compatibilidad.
• Evaluar integración modular.

Proyección futura: Inspiración en:

• Copyous
• Unclutter

Para desarrollar:

• Historial de portapapeles.
• Vista desplegable estilo panel.

Quick Settings Tweaks

Proyecto activo compatible hasta GNOME 48. Repositorio: Quick Settings Tweaks

Propuesta:

• Integración parcial de lógica.
• Evitar solapamientos.
• Unificar backend de configuración.
• Mantener modularidad.

Componentes a evaluar:

Media Widget

Notification Widget

Weather Widget

Layouts y configuraciones

• Reordenamiento de Quick Settings.
• Reordenamiento de indicadores del sistema.
• Configuración del Date Menu.
• Overlay Mode.

Panel Corners

Proyecto compatible hasta GNOME 48. Repositorio: Panel Corners

Objetivo:

• Adaptar compatibilidad a GNOME 50.
• Integrar como módulo visual independiente.
• Minimizar impacto en renderizado del Top Bar.

3. Arquitectura propuesta

3.1 Principios de diseño

• Separación de responsabilidades.
• Bajo acoplamiento
• Alta cohesión
• Gestión explícita del ciclo de vida.
• Evitar dependencia directa de APIs internar con poca documentación.

3.2 Estructura modular

extension/
  core/
    moduleLoader.js
    signalManager.js
    settingsManager.js
    logger.js
  modules/
    batteryBar/
    powerMenu/
    notificationIndicator/
    panelCorners/
    workspaceIndicator/
    mediaPlayer/
    dashboard/
    backgroundClock/
    quickText/
  utils/
    mprisService.js
    layoutHelpers.js

Otra propuesta más completa para la empezar:

Gnome-Widgets/
├── extension.js                 # Punto de entrada principal
├── metadata.json                # Configuración GNOME 50
├── prefs.js                     # Ventana de preferencias
├── LICENSE                      # GPL-3.0
├── README.md                    # Documentación
├── .gitignore
│
├── extension/
│   ├── core/
│   │   ├── moduleLoader.js      # Sistema de carga dinámmica
│   │   ├── signalManager.js     # Gestor central de signals (Gtk)
│   │   ├── settingsManager.js   # Wrapper para dconf/gsettings
│   │   └── logger.js            # Sistema de logging
│   │
│   ├── modules/
│   │   ├── batteryBar/
│   │   │   ├── module.js        # Interfaz estándar
│   │   │   ├── batteryBar.js    # Lógica
│   │   │   ├── batteryBar.css   # Estilos
│   │   │   └── settings.json    # Config por defecto
│   │   │
│   │   ├── powerMenu/
│   │   │   ├── module.js
│   │   │   ├── powerMenu.js
│   │   │   ├── powerMenu.css
│   │   │   └── settings.json
│   │   │
│   │   ├── notificationIndicator/
│   │   ├── panelCorners/
│   │   ├── workspaceIndicator/
│   │   ├── mediaPlayer/
│   │   ├── dashboard/
│   │   ├── backgroundClock/
│   │   ├── quickText/
│   │   └── _template/           # Template para nuevos módulos
│   │
│   └── utils/
│       ├── mprisService.js      # Interfaz MPRIS D-Bus
│       ├── layoutHelpers.js     # Helpers para UI
│       ├── gsettingsHelper.js   # Wrapper más avanzado
│       └── dBusHelper.js        # Utilidades D-Bus
│
├── schemas/
│   └── org.gnome.shell.extensions.gnome-widgets.gschema.xml
│
├── docs/
│   ├── DEVELOPMENT.md           # Guía de desarrollo
│   ├── MODULE_API.md            # API estándar de módulos
│   └── GNOME50_MIGRATION.md     # Notas para GNOME 50
│
└── tests/
    ├── core/
    └── modules/

3.3 Core Framework

Module Loader

• Carga y descarga dinámica de módulos.
• Activación condicional según configuración.
• Gestión de dependencias internas.

Signal Manager

• Registro centralizado.
• Desconexión automática en disable().
• Prevención de memory leaks.

Settings Manager

• Wrapper sobre GSettings.
• Observadores desacoplados.
• Actualización reactiva controlada.

Logger

• Sistema de depuración condicional.
• Activación en modo desarrollo.

4. Métodología de validación

Se utilizarán métricas como:

• Consumo de CPU en estado idle.
• Uso de memoria con múltiples módulos activos.
• Fluidez de animación del Overview.
• Ausencia de memory leaks tras ciclos enable/disable.

Pruebas:

1. Activación individual por módulo.
2. Activación combinada.
3. Prueba con extensiones externas activas.
4. Stress test de señales repetitivas.

Métricas de Calidad

• Tiempo de activación < 200 ms.
• Sin errores críticos en journalctl.
• Sin bloqueos del Shell.
• Sin degradación visible en FPS.
• Código documentado y modular.

5. Roadmap de implementación

Fase 0: Investigación (1 a 2 semanas)

Objetivos técnicos:

• Analizar cambios de API entre GNOME 44 → 50.
• Identificar breaking changes en GJS y GNOME Shell.
• Evaluar cambios en:
  • imports ESModules
  • señales y actores de Clutter
  • Quick Settings
  • Panel API
• Estudiar nuevas prácticas recomendadas.
• Mapear dependencias internas entre módulos.
• Definir arquitectura modular base.
• Definir contrato interno entre módulos (interfaces y responsabilidades).

Actividades:

• Auditoría de código actual.
• Identificación de puntos de acoplamiento fuerte.
• Diseño de:
  • Core Manager
  • Module Loader
  • Event Bus interno (si aplica)
• Definición de estrategia de lazy loading.

Entregables:

• Documento técnico de arquitectura.
• Diagrama de componentes.
• Lista priorizada de módulos.
• Plan de migración incremental.

Fase 1: Núcleo mínimo viable (3 a 4 semanas)

Objetivo: Extensión funcional y estable en GNOME 50 con núcleo modular.

Implementar:

• Sistema de configuración unificado (GSettings centralizado).
• Loader modular (activación/desactivación dinámica).
• Battery Bar.
• Power Menu.
• Notification Indicator.
• Panel Corners.

Criterios técnicos:

• Compatibilidad total con GNOME 50 beta.
• Ausencia de errores críticos en journalctl.
• Sin bloqueos del Shell.
• Sin listeners globales innecesarios.
• Sin memory leaks detectables.

Prioridades:

• Estabilidad > nuevas funcionalidades.
• No degradar rendimiento del panel.
• Diseño desacoplado entre módulos.

Resultado esperado:

Extensión estable y modular en estado preliminar.

Fase 2: Módulos interactivos (4 - 6 semanas)

Objetivo: Incorporar funcionalidades con mayor interacción y estado.

Implementar:

• Media Player (backend MPRIS unificado).
• Workspace Indicator.
• Dashboard simplificado.

Enfoque de desarrollo:

• Reutilización de código.
• Minimización de listeners globales.
• Gestión eficiente de señales.
• Optimización de redraw.
• Separación estricta entre lógica y UI.

Requisitos técnicos:

• Sin polling innecesario.
• Uso controlado de señales MPRIS.
• Desacoplamiento entre backend y frontend visual.
• Pruebas con múltiples extensiones activas.

Resultado esperado: Sistema interactivo robusto sin impacto perceptible en rendimiento.

Fase 3: Integración avanzada (4 semanas)

Objetivo: Extender capacidades sin comprometer estabilidad.

Implementar:

• Adaptación parcial de Quick Settings Tweak.
• Integración de Quick Text.
• Diseño unificado de preferencias.
• Refinamiento del Panel Corners (si requiere integración adicional).

Actividades técnicas:

• Refactor de preferencias para diseño consistente.
• Consolidación de esquema GSettings.
• Testing intensivo con:
  • múltiples extensiones activas
  • cambios dinámicos de configuración
  • reinicios de Shell

Criterios:

• Sin regresiones funcionales.
• Compatibilidad cruzada.
• Bajo consumo de memoria.

Resultado: Extensión madura, integrada y coherente en UX.

Fase 4: Optimización y refactor (2 semanas)

Objetivo: Consolidar calidad técnica antes de publicación estable.

Actividades:

• Profiling de rendimiento.
• Medición de consumo de memoria.
• Eliminación de código redundante.
• Reducción de acoplamientos innecesarios.
• Mejora de documentación técnica.
• Limpieza para publicación en extensions.gnome.org.

Herramientas:

• Looking Glass.
• journalctl.
• Instrumentación manual de tiempos críticos.

Criterios:

• Tiempo de carga optimizado.
• Bajo impacto en el render del panel.
• Código legible y mantenible.

Fase 5: Post lanzamiento

Implementar progresivamente:

• Historia de portapapeles estilo Unclutter
• Mantener arquitectura modular
• Mantenimiento y actualización

6. Riesgos y desafios

• Cambios futuros en GNOME 51 o posteriores.
• Dependencia de APIs no documentadas.
• Complejidad acumulativa por integración múltiple.
• Sobrecarga funcional si no se controla el alcance. Amplitud y dispersión: las extensiones que lo conforman son heterogéneas en propósito y complejidad. Esto puede dificultar la definición de un objetivo claro y acotado. Por ello, será fundamental adoptar un enfoque modular y establecer prioridades claras.

Se mitigarán mediante:

• Diseño modular estricto.
• Pruebas iterativas.
• Documentación constante.
• Priorización clara de módulos.

7. Resultados esperados

• Arquitectónicamente modular.
• Compatible con GNOME 50.
• Escalable.
• Mantenible.
• Publicable.
• Con base sólida para futuras versiones de GNOME.