GNOME Control Center: Personalización e integración de un panel propio en TitalcruiseOS

Guía técnica de desarrollo, compilación e instalación

Proyecto: Escritorio de TitalcruiseOS

Plataforma: TitalcruiseOS 5.4.1

Aplicación modificada: GNOME Control Center 51.1

Tecnologías: C, GTK, libadwaita, Blueprint, Meson, Ninja, GSettings y D-Bus

Fecha de documentación: 24 de octubre de 2026

Prólogo

GNOME Control Center es la aplicación de configuración del escritorio GNOME. Desde ella se administran aspectos como la apariencia, las pantallas, el sonido, las cuentas, el teclado y otros componentes del sistema.

Pero ¿qué ocurre cuando queremos integrar una función propia directamente en esa aplicación?

En este proyecto, el objetivo fue incorporar un panel nativo llamado «Escritorio de TitalcruiseOS», dedicado a configurar determinadas opciones de la extensión Dash to Panel de GNOME Shell.

La intención no era crear una aplicación independiente ni limitarse a cambiar el tema visual. Se buscaba integrar una sección propia dentro de la arquitectura de GNOME Control Center, compilarla junto con el resto de la aplicación e instalarla para todos los usuarios del equipo.

El camino incluyó varios desafíos: adaptar las dependencias de compilación, registrar correctamente el panel, conservar la identidad visual del sistema y resolver una discrepancia entre el ejecutable personalizado y el que se utilizaba al abrir Configuración desde el escritorio.

Este libro documenta ese recorrido, sus decisiones técnicas, los problemas encontrados y el resultado obtenido.

Capítulo 1. El objetivo del proyecto

1.1. ¿Qué queríamos construir?

El objetivo principal era añadir una nueva sección al menú lateral de GNOME Control Center con el nombre:

Escritorio de TitalcruiseOS

Este panel permitiría administrar opciones de Dash to Panel sin tener que abrir su interfaz de preferencias por separado.

La interfaz se diseñó con componentes de GTK y libadwaita para mantener una apariencia coherente con GNOME.

1.2. Las funciones previstas

El panel incluye dos grupos principales de preferencias.

Barra de tareas

• Posición de la barra: abajo, arriba, izquierda o derecha.

• Tamaño de la barra mediante un control numérico.

• Activación o desactivación del soporte para múltiples monitores.

Apariencia

• Activación del fondo personalizado.

• Campo para especificar el color de fondo.

• Activación de la opacidad personalizada.

• Control numérico de la opacidad.

Estas opciones se relacionan con las preferencias que ofrece la extensión Dash to Panel.

Es importante distinguir entre la interfaz y su funcionamiento: mostrar un control en pantalla no demuestra por sí solo que el cambio se aplique correctamente. Cada opción debe conectarse a su correspondiente ajuste y probarse individualmente.

1.3. ¿Por qué modificar GNOME Control Center?

Una aplicación independiente habría permitido controlar algunas de estas preferencias, pero no habría cumplido el objetivo de integrar la funcionalidad en el menú lateral nativo de Configuración.

Por eso se eligió modificar el código fuente de GNOME Control Center.

El resultado buscado era una sección que formara parte de la aplicación, con su propio identificador de panel y sus archivos de interfaz, recursos y metadatos.

Capítulo 2. Preparación del entorno de desarrollo

2.1. Código fuente

El proyecto se trabajó en el siguiente directorio:

~/Descargas/gnome-control-center-debian-latest

La versión compilada fue GNOME Control Center 51.1.

La compilación se realizó con Meson y Ninja, herramientas utilizadas para configurar y construir proyectos de software.

2.2. Una dependencia incompatible

Durante la preparación inicial apareció un problema relacionado con AccountsService.

El código fuente requería una versión mínima de AccountsService 26.27.3, mientras que el sistema disponía de la versión 23.13.9.

La configuración inicial de Meson no pudo continuar con esa combinación de requisitos.

En este caso se aplicó un parche de Debian que revierte un cambio relacionado con la conservación de datos al eliminar un usuario de tipo homed.

El parche utilizado fue:

patch -p1 < \
  debian/patches/Revert-users-Disable-keeping-data-if-deleting-homed-user.patch

Después se volvió a configurar el directorio de compilación:

meson setup --wipe build

La configuración terminó correctamente.

Nota técnica: aplicar un parche de compatibilidad no significa que todas las diferencias entre las dependencias hayan desaparecido. Es necesario entender qué modifica el parche y comprobar que el comportamiento requerido siga siendo correcto.

Capítulo 3. Creación del panel personalizado

3.1. Estructura de archivos

Se creó el directorio:

panels/titalcruise-desktop/

Dentro se incorporaron los siguientes archivos:

panels/titalcruise-desktop/
├── cc-titalcruise-desktop-panel.h
├── cc-titalcruise-desktop-panel.c
├── cc-titalcruise-desktop-panel.blp
├── titalcruise-desktop.gresource.xml
├── gnome-titalcruise-desktop-panel.desktop.in
└── meson.build

Cada archivo cumple una función específica.

Archivo	Responsabilidad
cc-titalcruise-desktop-panel.h	Declaración de la clase del panel.
cc-titalcruise-desktop-panel.c	Implementación y lógica del panel en C.
cc-titalcruise-desktop-panel.blp	Descripción de la interfaz con Blueprint.
titalcruise-desktop.gresource.xml	Registro de los recursos utilizados por la interfaz.
gnome-titalcruise-desktop-panel.desktop.in	Plantilla de los metadatos del panel.
meson.build	Configuración de compilación e instalación del subdirectorio.

Esta separación permite mantener el código, la interfaz y los recursos organizados.

3.2. Interfaz con Blueprint

La interfaz se definió mediante Blueprint, que permite describir componentes GTK de forma declarativa.

El panel utiliza una página de preferencias de libadwaita y organiza sus controles en grupos.

Entre los componentes utilizados se encuentran filas de preferencias, interruptores, campos de entrada y controles numéricos.

La ventaja de este enfoque es que la estructura visual queda separada de la lógica de programación escrita en C.

3.3. Registro en Meson

El archivo meson.build del panel permite integrarlo en el proceso de construcción.

Además, se añadió el directorio del panel a la configuración general de:

panels/meson.build

Sin este registro, los archivos podrían existir en el árbol de código fuente sin formar parte de la compilación principal.

3.4. Registro en el cargador de paneles

Uno de los pasos esenciales consistió en registrar el tipo del panel en:

shell/cc-panel-loader.c

Se utilizó la declaración:

extern GType cc_titalcruise_desktop_panel_get_type(void);

Y se añadió el identificador del panel al registro:

PANEL_TYPE (
    "titalcruise-desktop",
    cc_titalcruise_desktop_panel_get_type,
    NULL
)

El identificador titalcruise-desktop permite solicitar la apertura del panel mediante la línea de comandos.

Por ejemplo:

./build/shell/gnome-control-center titalcruise-desktop

Este registro es fundamental. Un archivo .desktop por sí solo no convierte una página en un panel nativo: el programa también debe conocer su tipo y saber cómo cargarlo.

Capítulo 4. El registro del panel en el escritorio

4.1. Metadatos del panel

Se creó una plantilla de archivo .desktop con información como el nombre, la descripción, el icono y las palabras clave.

La plantilla genera un archivo llamado:

gnome-titalcruise-desktop-panel.desktop

Entre sus entradas se encuentran:

Name=Escritorio de TitalcruiseOS
Comment=Configurá la barra de tareas y su apariencia
Exec=gnome-control-center titalcruise-desktop
Icon=preferences-desktop-panel-symbolic
NoDisplay=true

La propiedad NoDisplay=true evita que el panel aparezca como una aplicación independiente en los lanzadores habituales.

No impide que GNOME Control Center lo muestre dentro de su propio menú lateral.

4.2. Un problema de descubrimiento

Al principio, el panel no aparecía en la lista de paneles disponibles, aunque el código estaba compilado.

El motivo era que GNOME Control Center intentaba localizar los metadatos mediante los directorios de aplicaciones conocidos por el sistema, no directamente dentro del directorio de compilación.

Durante las pruebas se resolvió colocando el archivo generado en el directorio de aplicaciones del usuario:

mkdir -p ~/.local/share/applications

cp build/panels/titalcruise-desktop/gnome-titalcruise-desktop-panel.desktop \
  ~/.local/share/applications/

Después de ese paso, el panel comenzó a aparecer al consultar la lista de paneles de la compilación.

Este hallazgo demuestra que compilar un componente y lograr que la aplicación lo descubra son dos tareas diferentes.

Capítulo 5. La primera compilación satisfactoria

Una vez integrados los archivos del panel, se ejecutó la compilación principal:

ninja -C build

El resultado final fue:

[775/775] Linking target tests/interactive-panels/test-interactive-panels

La compilación terminó correctamente.

También se comprobó que el panel podía abrirse desde el directorio de compilación:

./build/shell/gnome-control-center titalcruise-desktop

Las pruebas con la opción --verbose indicaron que el panel se abría correctamente.

En esta etapa ya se había conseguido lo esencial desde el punto de vista del desarrollo: el nuevo panel formaba parte de la compilación y podía cargarse.

Sin embargo, todavía faltaba resolver la identidad visual y la instalación global.

Capítulo 6. Recuperación del logo de TitalcruiseOS

6.1. El problema visual

Después de compilar la versión personalizada, se observó que la sección «Acerca del sistema» mostraba el logo de GNOME en lugar del esperado para TitalcruiseOS.

La investigación mostró que el código de la página de información del sistema consultaba el valor LOGO mediante g_get_os_info() y utilizaba un logo genérico de GNOME como alternativa cuando no encontraba uno adecuado.

El archivo /etc/os-release incluía:

PRETTY_NAME="TitalcruiseOS 5.4.1"
NAME="TitalcruiseOS"

Pero no incluía una entrada LOGO.

6.2. Configuración de compilación

El archivo principal meson.build ofrecía una opción de compilación denominada distributor_logo.

Se configuró con:

meson configure build \
  -Ddistributor_logo=/usr/share/pixmaps/debian-logo.png

Después se comprobó la existencia del archivo:

test -f /usr/share/pixmaps/debian-logo.png \
  && echo "Logo encontrado"

La compilación se actualizó:

ninja -C build

El archivo build/config.h confirmó la configuración:

#define DISTRIBUTOR_LOGO "/usr/share/pixmaps/debian-logo.png"

Finalmente, se verificó visualmente que el logo esperado aparecía correctamente.

Este paso permitió conservar la identidad visual del sistema sin modificar /etc/os-release.

Capítulo 7. Instalación global

7.1. ¿Por qué instalar en /usr/local?

Se eligió instalar la compilación personalizada para todos los usuarios, manteniendo la versión original del sistema.

La configuración de Meson indicaba:

prefix    /usr/local
bindir    bin
datadir   share
libdir    lib/x86_64-linux-gnu
libexecdir libexec

Esto situó el ejecutable personalizado en:

/usr/local/bin/gnome-control-center

Y el panel en:

/usr/local/share/applications/gnome-titalcruise-desktop-panel.desktop

La instalación se realizó con:

sudo meson install -C build --no-rebuild

El proceso instaló el programa, los recursos, las traducciones, los archivos de datos y otros componentes del proyecto.

7.2. Protección de la versión original

Antes de instalar, se creó una copia de seguridad del ejecutable original:

sudo cp -a \
  /usr/bin/gnome-control-center \
  /usr/bin/gnome-control-center.backup-antes-titalcruise

Esto permitió mantener el ejecutable original disponible para una recuperación posterior.

Se comprobó que el ejecutable personalizado existía:

ls -l /usr/local/bin/gnome-control-center

También se verificó que ambas versiones informaban la versión 51.1.

Aunque el número de versión coincidía, sus compilaciones no eran funcionalmente idénticas: la de /usr/local incluía las modificaciones del proyecto.

7.3. Una instalación no garantiza el uso predeterminado

En este punto, el panel podía abrirse con:

/usr/local/bin/gnome-control-center titalcruise-desktop

Sin embargo, al abrir Configuración desde el escritorio, el panel no aparecía.

La instalación global había terminado, pero la aplicación utilizada por la sesión gráfica todavía no era necesariamente la personalizada.

Ese fue el siguiente problema que hubo que investigar.

Capítulo 8. El misterio de las dos versiones

8.1. La primera pista: PATH

Se ejecutó:

command -v gnome-control-center

El resultado fue:

/usr/local/bin/gnome-control-center

La variable PATH comenzaba por:

/usr/local/bin:/usr/bin:/bin

Por lo tanto, una orden ordinaria ejecutada desde esa terminal encontraba primero el ejecutable personalizado.

Esto explicaba por qué el siguiente comando funcionaba:

gnome-control-center titalcruise-desktop

Pero no explicaba por qué el panel desaparecía al abrir Configuración desde el escritorio.

8.2. La segunda pista: los lanzadores

Se inspeccionaron los archivos de Configuración:

/usr/share/applications/org.gnome.Settings.desktop
/usr/local/share/applications/org.gnome.Settings.desktop

Ambos incluían:

Exec=gnome-control-center
DBusActivatable=true

La opción DBusActivatable=true indica que el escritorio puede utilizar la activación de D-Bus para abrir la aplicación.

Por eso no bastaba con mirar el valor de PATH.

8.3. El archivo decisivo

Se examinó el servicio de D-Bus del sistema:

/usr/share/dbus-1/services/org.gnome.Settings.service

Su contenido original era:

[D-BUS Service]
Name=org.gnome.Settings
Exec=/usr/bin/gnome-control-center --gapplication-service

La línea Exec utilizaba una ruta absoluta.

Esto significaba que la activación del servicio no dependía del orden de directorios en PATH. Aunque la terminal utilizara la versión de /usr/local, el servicio de D-Bus podía iniciar explícitamente la versión de /usr/bin.

La diferencia entre ambos mecanismos era la clave del problema.

Capítulo 9. La solución de D-Bus

9.1. Copia de seguridad del servicio original

Antes de modificar el archivo, se guardó una copia:

sudo cp -a \
  /usr/share/dbus-1/services/org.gnome.Settings.service \
  /usr/share/dbus-1/services/org.gnome.Settings.service.backup

Esta copia permite recuperar el contenido anterior si fuera necesario.

9.2. Cambio del ejecutable

Se modificó el archivo de servicio para utilizar la compilación personalizada:

sudo tee /usr/share/dbus-1/services/org.gnome.Settings.service <<'EOF'
[D-BUS Service]
Name=org.gnome.Settings
Exec=/usr/local/bin/gnome-control-center --gapplication-service
EOF

El contenido resultante fue:

[D-BUS Service]
Name=org.gnome.Settings
Exec=/usr/local/bin/gnome-control-center --gapplication-service

La identidad D-Bus del servicio siguió siendo org.gnome.Settings. Lo que cambió fue el

ejecutable que se iniciaría al activar el servicio.

9.3. ¿Por qué no se reemplazó el binario original?

Porque el problema estaba en la ruta utilizada para iniciar la aplicación, no en la existencia del ejecutable original.

Conservar /usr/bin/gnome-control-center y su copia de seguridad evitó tener que sustituir directamente el archivo proporcionado por el sistema.

9.4. La prueba definitiva

Después de modificar el servicio, se cerraron las ventanas de Configuración y se abrió nuevamente la aplicación desde el escritorio.

El panel «Escritorio de TitalcruiseOS» apareció en el menú lateral.

Con esto se confirmó que la integración no dependía únicamente de abrir el ejecutable personalizado manualmente.

El acceso habitual a Configuración también podía utilizar la compilación que incluía el nuevo panel.

9.5. Una nota importante sobre las rutas de D-Bus

Durante la investigación también se encontró el archivo:

/usr/local/share/dbus-1/services/org.gnome.Settings.service

Este archivo ya apuntaba al ejecutable personalizado.

Sin embargo, tener dos archivos con el mismo nombre de servicio en distintos directorios no garantiza cuál será seleccionado por el mecanismo de activación. La elección depende de las rutas y las reglas de búsqueda aplicadas por el entorno.

Por eso se corrigió el archivo de servicio que se había identificado como problemático.

El cambio realizado en /usr/share debe documentarse porque una actualización del paquete de GNOME Control Center podría restaurar el archivo original. Si eso ocurre, el problema puede reaparecer.

Capítulo 10. Cómo comprobar y mantener el resultado

10.1. Verificar el ejecutable

Para comprobar qué binario encuentra la terminal:

command -v gnome-control-center

Para abrir directamente el panel personalizado:

/usr/local/bin/gnome-control-center titalcruise-desktop

Para mostrar la lista de paneles disponibles:

/usr/local/bin/gnome-control-center --list

La salida debe permitir comprobar si el identificador titalcruise-desktop está registrado.

10.2. Verificar los archivos de servicio

El servicio de D-Bus modificado puede inspeccionarse con:

cat /usr/share/dbus-1/services/org.gnome.Settings.service

La copia de seguridad se conserva en:

/usr/share/dbus-1/services/org.gnome.Settings.service.backup

La copia del ejecutable original se conserva en:

/usr/bin/gnome-control-center.backup-antes-titalcruise

Son dos copias de seguridad diferentes: una corresponde al ejecutable y otra al archivo de activación de D-Bus.

10.3. Actualizar el código fuente

Si se realizan cambios en los archivos del panel, el procedimiento normal consiste en recompilar:

ninja -C build

Si los cambios requieren actualizar los archivos instalados, se puede volver a ejecutar el proceso de instalación:

sudo meson install -C build --no-rebuild

Debe comprobarse que la instalación se haya realizado correctamente y que los recursos y metadatos del panel estén actualizados.

10.4. Precauciones de mantenimiento

Hay tres aspectos que conviene tener presentes.

1. Primero: la instalación bajo /usr/local mantiene separado el ejecutable personalizado del original, pero no impide que otros mecanismos del escritorio sigan utilizando una ruta absoluta hacia /usr/bin.

2. Segundo: el cambio en /usr/share/dbus-1/services puede ser reemplazado por una actualización del paquete. Después de actualizar GNOME Control Center, conviene revisar el archivo.

3. Tercero: los controles del panel deben probarse de forma individual. Es necesario verificar que cada ajuste modifique el valor correcto de GSettings y que su efecto se refleje realmente en Dash to Panel.

Una interfaz visible es el comienzo de la integración, no la garantía de que toda la lógica esté terminada.

Capítulo 11. El resultado del proyecto

El proyecto consiguió los siguientes resultados:

1. Se modificó el código fuente de GNOME Control Center 51.1.

2. Se creó un panel propio denominado «Escritorio de TitalcruiseOS».

3. Se integró el panel en el registro de tipos y en el sistema de compilación.

4. Se construyó correctamente la aplicación con Ninja.

5. Se recuperó el logo esperado mediante una opción de compilación.

6. Se instaló la versión personalizada globalmente bajo /usr/local.

7. Se conservó una copia de seguridad del ejecutable original.

8. Se identificó la activación de D-Bus como causa de que el escritorio utilizara otra versión.

9. Se modificó el archivo de servicio para apuntar a la compilación personalizada.

10. Se confirmó que el panel aparecía al abrir Configuración normalmente.

El resultado final fue una versión personalizada de GNOME Control Center con una sección propia integrada en el menú lateral de Configuración.

El logro principal no consistió solamente en crear una página de preferencias. También fue necesario integrar esa página en el cargador de paneles, incorporarla al proceso de compilación, instalarla en el sistema y corregir el mecanismo que determinaba qué versión de la aplicación se iniciaba.

Capítulo 12. Preguntas frecuentes

• Pregunta 1. ¿Cómo puedo reparar el problema de que mi panel personalizado no aparece en Configuración?

Descripción: El panel se abre mediante una orden manual, pero desaparece al iniciar Configuración desde el escritorio.

Respuesta:

Primero hay que distinguir entre el ejecutable que se invoca desde la terminal y el que utiliza la sesión gráfica.

Se puede comprobar el primero con:

command -v gnome-control-center

Después hay que inspeccionar el lanzador de Configuración y el archivo de activación de D-Bus:

/usr/share/applications/org.gnome.Settings.desktop
/usr/share/dbus-1/services/org.gnome.Settings.service

Si el servicio utiliza una ruta absoluta hacia /usr/bin/gnome-control-center, puede estar iniciando la versión original en lugar de la personalizada.

En este proyecto se corrigió la entrada Exec del servicio para apuntar a /usr/local/bin/gnome-control-center, después de guardar una copia de seguridad. La prueba final confirmó que el panel aparecía al abrir Configuración desde el escritorio.

• Pregunta 2. ¿Qué es GNOME Control Center y para qué sirve un panel personalizado?

Descripción: Se necesita entender qué se modificó y por qué no bastaba con crear una aplicación independiente.

Respuesta:

GNOME Control Center es la aplicación de configuración del entorno de escritorio GNOME.

Un panel es una sección interna de esa aplicación que permite administrar un conjunto de preferencias relacionadas.

En este proyecto se creó «Escritorio de TitalcruiseOS» para reunir controles de posición, tamaño y apariencia de la barra de tareas gestionada por Dash to Panel.

Para que funcionara como panel nativo, fue necesario implementar la clase en C, definir la interfaz, registrar los recursos, incorporar el subdirectorio a Meson y registrar el identificador del panel en el cargador de GNOME Control Center.

• Pregunta 3. ¿Qué diferencia hay entre instalar GNOME Control Center en /usr/bin y en /usr/local/bin?

Descripción: Se busca comprender por qué se conservaron dos ejecutables.

Respuesta:

/usr/bin suele contener ejecutables instalados y administrados por el sistema de paquetes de la distribución.

/usr/local/bin se utiliza habitualmente para software instalado localmente, fuera de la gestión ordinaria de esos paquetes.

Instalar la compilación personalizada bajo /usr/local permitió mantenerla separada de la versión original de TitalcruiseOS.

Sin embargo, esa separación no garantiza que todos los lanzadores utilicen la nueva versión. Si un servicio contiene una ruta absoluta hacia /usr/bin, ejecutará ese archivo independientemente del orden de PATH.

Por eso también fue necesario revisar la activación de D-Bus.

• Pregunta 4. ¿Por qué fue necesario modificar el archivo de servicio de D-Bus?

Descripción: Se quiere entender el papel de D-Bus en el inicio de la aplicación.

Respuesta:

D-Bus es un sistema de comunicación entre procesos que permite que distintas aplicaciones y componentes soliciten servicios.

En este caso, el archivo org.gnome.Settings.service especificaba qué ejecutable debía iniciarse para atender el servicio org.gnome.Settings.

La entrada original utilizaba:

Exec=/usr/bin/gnome-control-center --gapplication-service

La versión personalizada se encontraba en /usr/local/bin. Por ello, se cambió la ruta del servicio y se conservó el mismo nombre de servicio.

Después de cerrar y abrir Configuración desde el escritorio, el panel personalizado apareció correctamente.

Como el archivo modificado está bajo /usr/share, una actualización del paquete podría restaurar su contenido anterior. Es recomendable conservar la copia de seguridad y revisar el servicio después de las actualizaciones pertinentes.

• Pregunta 5. ¿Cómo puedo comprobar que un panel nuevo está realmente integrado en GNOME Control Center?

Descripción: Se necesita distinguir una compilación correcta de una integración funcional.

Respuesta:

La comprobación debe realizarse por etapas.

1. Compilación: ejecutar ninja -C build y verificar que termine sin errores.

2. Registro: comprobar que el identificador del panel esté registrado en el cargador de paneles.

3. Metadatos: verificar que exista el archivo .desktop generado y que la aplicación pueda descubrirlo.

4. Apertura directa: ejecutar /usr/local/bin/gnome-control-center titalcruise-desktop.

5. Instalación: comprobar que el ejecutable, los recursos y los metadatos estén instalados en las rutas esperadas.

6. Inicio normal: abrir Configuración desde el escritorio y verificar que el panel aparezca en el menú lateral.

7. Pruebas funcionales: modificar cada preferencia y comprobar que el valor correspondiente cambie y que el efecto sea visible.

En este proyecto, las pruebas confirmaron la compilación, la apertura directa, la instalación global y la aparición del panel al iniciar Configuración normalmente. La comprobación individual de todos los controles sigue siendo una etapa funcional distinta que conviene completar.

Epílogo

Este proyecto demuestra que personalizar un escritorio Linux puede ir mucho más allá de cambiar iconos, fondos o temas.

Se modificó una aplicación central de GNOME, se creó una sección propia, se integró en el proceso de construcción y se instaló globalmente. También se investigó una diferencia entre la resolución de ejecutables de la terminal y la activación de aplicaciones mediante D-Bus.

La lección técnica más importante es que compilar, instalar, registrar e iniciar correctamente una aplicación son etapas diferentes. Una aplicación puede compilar sin errores y estar instalada en el sistema, pero aun así no ser la versión que abre el escritorio.

En este caso, resolver esa última diferencia permitió que el panel «Escritorio de TitalcruiseOS» pasara de ser una función accesible únicamente mediante un comando a formar parte de la experiencia habitual de Configuración.

El resultado es una base concreta para continuar desarrollando una experiencia de escritorio propia, con identidad visual y herramientas integradas en el entorno GNOME.

Vista previa de "Escritorio de TitalcruiseOS"

Titalcruise E.A.