Cómo solucionar errores de visualización en aplicaciones Qt en entornos GTK.

Al estar dentro de un entorno GTK (GIMP Toolkit), podemos necesitar instalar (y es casi seguro que lo terminemos haciendo) aplicaciones basadas en Qt.

Los entornos GTK, comúnmente involucran a escritorios como Mate, Cinnamon, XFCE, LXDE, y otro lamentablemente muy popular e innombrable por tosco y contraintuitivo, entre otras abominaciones impías que contiene.
Dentro del entorno Qt (no se sabe qué significa esta sigla a ciencia cierta), encontramos a Plasma ("KDE") y a LXQt, entre algunos otros.

De aquí se desprende que al pretender instalar, por ejemplo, "Kolourpaint" (diseñado por KDE, basado en Qt) en un entorno "XFCE" (basado en GTK), es posible que tengamos algunos problemas de funcionamiento (o más frecuentemente, de visualización) de esa aplicación.

Un mensaje que puede aparecer al ejecutar aplicaciones Qt por terminal o al abrir qt5ct es algo como: "No se ha configurado la variable de entorno QT_QPA_PLATFORMTHEME", o incluso algo más explícito como "No se ha configurado la variable de entorno QT_QPA_PLATFORMTHEME (valores obligatorios: qt5ct o qt6ct).". Esto está indicando que falta definir un tema para las aplicaciones Qt.

¿Notás la casi invisibilidad de íconos fundamentales para el uso de esta aplicación, en la columna izquierda de la misma?
Este es el error de visualización del cual te hablaba.
¿Cómo se puede solucionar?
¡Vamos a ello!

Instalá el paquete "qt5ct" con sudo y...
pacman -S qt5ct # para Arch y sistemas basados en él,
apt install qt5ct # para Debian y sistemas basados en él,

etc.

Ejecutá en terminal el comando sudo nano /etc/environment, y agregale la línea QT_QPA_PLATFORMTHEME=qt5ct, tal como se ve en la imagen.
Guardá con [CTRL][O] y salí de nano con [CTRL][X].


Ahora tendrías que cerrar tu sesión de usuario y volver a abrirla, y de no funcionar esto, reiniciar directamente el sistema.

Podrías instalar también al paquete "adwaita-qt" (sudo apt install adwaita-qt para Debian, sudo pacman -S adwaita-qt5 para Arch), el cual es un "tema" que puede que quede mejor con el estilo de entornos GTK y que podrías aplicarle a los programas basados en Qt (aunque esto generalmente no sea estrictamente necesario).

Abrí qt5ct, andá a la pestaña "Tema de iconos", seleccioná un tema de íconos (por ejemplo "Brisa" u "Oxígeno"), y hacé clic en "Aplicar". Luego, abrí a KolourPaint (o a la aplicación que te esté generando inconvenientes de visualización), y fijate cómo luce.

Asegurate de que los paquetes "breeze-icons" u "oxygen-icons" estén instalados (los cuales suelen venir "integrados" con KolourPaint o qt5ct), o estos juegos de íconos podrían no aparecer.

¿Lo ves? ¡Quedó finalizado!
Lo bueno es que una vez que realizás este procedimiento para una aplicación Qt, las demás aplicaciones del mismo tipo, deberían verse bien, también.

Si querés, por curiosidad nomás y para asegurarte de que todo está en orden en este aspecto, ejecutá en terminal echo $QT_QPA_PLATFORMTHEME
La terminal debería responderte qt5ct

Cómo subir más archivos o carpetas a un proyecto existente de Codeberg.

 

Cómo subir más archivos o carpetas a un proyecto existente de Codeberg.

1. Verificá si estás en la rama correcta en CodeBerg (por ejemplo, "main" o "master"):

git branch

Esto te mostrará la rama actual (marcada con un "*"). Si ves que no estás en la rama correcta, cambiala con:

git checkout nombre_de_la_rama

2. [OPCIONAL] Confirmá, también, que los archivos estén en el repositorio local:

ls -R

Esto listará todos los archivos y carpetas de tu proyecto en tu computadora. Si los mismos no aparecen, verificá si realmente los creaste (o copiaste, o moviste) correctamente al directorio local del proyecto.

3. Añadí los archivos y/o directorios al control de versiones del próximo "commit":

git add directorio_1
git add directorio_2
git add archivo_1
git add archivo_2

etc.

Si los elementos son muchos y querés agregarlos a todos de una sola vez, podés hacer "git add ."

Nota: Git ignora a las carpetas vacías: de ser este el caso, Git no las subirá. Asegurate de que los archivos necesarios estén dentro.

4. Creá un "commit" con los cambios. Ejemplo:

git commit -m "Se agrega un directorio conteniendo 3 archivos."

5. Subí todo a la rama remota:

git push origin nombre_de_la_rama

¡Pronto!

Subir un archivo tipo "fork" a un proyecto existente en CodeBerg, sustituyendo al que ya está allí.


Dado que ya existen en el blog otros 2 artículos que abordan temáticas relativas a CodeBerg, asumiré que en este caso, las referencias y explicaciones correspondientes a cada uno de estos pasos que veremos, se podrán consultar allí si es necesario. Los podés consultar desde acá mismo:

Brevísimo manual para subir scripts BASH a Codeberg: https://entropiabinaria.blogspot.com/2025/06/brevisimo-manual-para-subir-scripts.html

Cambiar el nombre de un proyecto (y de sus archivos) en CodeBerg sin perder el historial: https://entropiabinaria.blogspot.com/2025/07/cambiar-el-nombre-de-un-proyecto-y-de.html

En esta entrada, preferimos ser directos, para no terminar siendo redundantes.

Estos son los pasos concisos para reemplazar un archivo ya alojado en CodeBerg (en este caso "monitux.sh") con otro que lo reemplazará (en nuestro ejemplo, "big_monitux.sh"), manteniendo el historial.

Abrí la terminal en el directorio en donde tenés al archivo nuevo o "fork", o abrí una terminal y andá hasta la carpeta local de tu repositorio (monitux).

  1. Hacé git pull origin main (1)
  2. Luego, rm monitux.sh (tené cuidado, que acá estás eliminando un archivo localmente, ¡hacé respaldo!)
  3. Después, mv big_monitux.sh monitux.sh
  4. A continuación, git add monitux.sh
  5. Hacé un "commit" para explicar estos cambios: git commit -m "Se fusionaron las funcionalidades de rotación de 'rotéitor.sh' con las de encendido y apagado de pantallas de 'pantallas.sh', creándose así 'monitux.sh'."
  6. Ahora: git push origin main (2)

¡Listo! Una vez hecho esto, el nuevo archivo (ahora sí, "monitux.sh") habrá quedado como sustituto del anterior "monitux.sh" en tu espacio en Codeberg, con su historial intacto.

NOTAS IMPORTANTES. 

(1) Si tenés problemas ya de entrada, hacé lo siguiente:
ejecutá "git remote -v", y si no ves "origin" apuntando a la URL indicada (la cual en este caso de ejemplo, sería "https://codeberg.org/entropiabinaria/monitux.git"), entonces...

Hacé un "git remote add origin <URL_de_tu_proyecto.git>" (en este caso: "git remote add origin https://codeberg.org/entropiabinaria/monitux.git")
Si en este paso, la terminal te devuelve "error: remoto origin ya existe", hacé
"git remote remove origin" y "git remote add origin https://codeberg.org/entropiabinaria/monitux.git".

Al hacer de nuevo un "git remote -v", esta vez verás algo así:
origin  https://codeberg.org/entropiabinaria/monitux.git (fetch)
origin  https://codeberg.org/entropiabinaria/monitux.git (push)

Hacé el paso 2 de la lista de arriba.
Ahora hacé el paso 1.
Ahora, seguí a partir del paso 3. Ya no deberían darse más errores.

(2) Si en este paso, la terminal te dice
error: src refspec main no concuerda con ninguno
error: falló el empuje de algunas referencias a '<URL_de_tu_proyecto.git>'

hacé:
"git push --set-upstream origin main", o, en caso de error "git push --set-upstream origin master:main".

Cambiar el nombre de un proyecto (y de sus archivos) en CodeBerg sin perder el historial.

Ayer me encontraba en la situación de haberle cambiado de nombre a un script en mi máquina, y como necesitaba subirlo a CodeBerg, quería cambiarle de nombre también al proyecto que ya estaba alojado allí. El anterior era "pantallas.sh" y su URL era "https://codeberg.org/entropiabinaria/pantallas", pero yo quería que el script cambiara su nombre dentro de CodeBerg a "monitux.sh", y que su URL pasara a ser "https://codeberg.org/entropiabinaria/monitux" pero sin perder el "historial" anterior, ya que "monitux.sh" era un "fork-actualización" de "pantallas.sh".
Esta es una situación bastante común cuando los proyectos evolucionan. Uno quiere mantener el historial de cambios (el "progreso" anterior) y, al mismo tiempo, reflejar el nuevo nombre del script y del repositorio.

Te cuento una solución posible, que fue la que apliqué (y la que seguiré aplicando cada vez que se plantee la misma situación). Lo que hice fue esto: renombré (con el comando "git") al archivo nuevo y renombré también al repositorio en CodeBerg (utilizando la interfaz web del sitio).

Los pasos que realicé, fueron, en resumidas cuentas, los siguientes:

1. renombré al archivo localmente (utilizando "git"),
2. hice un "commit" de ese renombramiento,
3. subí los nuevos archivos a CodeBerg,
4. renombré al repositorio utilizando "la interfaz" de CodeBerg,
5. actualicé localmente la URL vieja por la nueva, para que git se enterara del "nuevo repositorio correspondiente al mismo proyecto".

NOTA MUY IMPORTANTE: si te pasó lo mismo y querés solucionarlo siguiendo esta guía, te recomiendo que lo hagas únicamente cuando tengas un rato libre y que no interrumpas el proceso hasta finalizarlo. De lo contrario, pueden surgir errores inesperados que te harán perder tiempo buscando soluciones a problemas que no existían. 

Ahora, sí: ¡vamos a ello!

I) Abrí la terminal en el directorio de tu script anterior (ejemplo, "pantallas.sh").
Asegurate de que tu directorio local esté limpio (sin cambios pendientes):

git status


Si hay cambios, hacé un "git add ." y git commit -m "Mensaje" o un "git stash" para guardarlos temporalmente.

II) Renombrá el archivo anterior (pantallas.sh) a "monitux.sh" usando "git".
El siguiente comando le indicará a git que el archivo se ha movido o renombrado. De otro modo, CodeBerg "pensaría" que se eliminó y que se creó uno nuevo. Este paso es sumamente importante a efectos de poder conservar todo el historial anterior (los "commits", las ramas, los "issues" y cualquier contribución anteriormente realizada, para no tener que eliminar todo, empezar desde cero y perder la trazabilidad de los cambios).

git mv pantallas.sh monitux.sh


Si tenés otros archivos o carpetas que también cambiaron de nombre o se relacionaban con el viejo nombre y ahora con "monitux", también renombralos con "git mv". Por ejemplo, si tenés una carpeta "docs-pantallas" que ahora es "docs-monitux":

git mv docs-pantallas docs-monitux

Verificá el cambio con "git status".
Deberías ver algo como: "renamed: pantallas.sh -> monitux.sh".

Confirmá (commit) el renombramiento:

git commit -m "Se ha renombrado 'pantallas.sh' como 'monitux.sh' para reflejar el nuevo nombre del script y del proyecto."

III) Subí estos cambios a Codeberg:

git push origin main

En este punto, si vas a CodeBerg, verás que en tu repositorio "pantallas", ahora existe "monitux.sh" y que el antiguo "pantallas.sh" ya no existe, porque fue renombrado. Git "sabe" que este es el mismo archivo y que el historial es continuo e involucra a ambos.

IV) Ahora dirigite a CodeBerg con el navegador, y andá a tu repositorio "pantallas" (el que pasará a ser el "viejo" en minutos).
Hacé clic en "Configuración" en la barra de navegación del repositorio (este botón se encuentra casi en el ángulo superior derecho).
En la página de configuración, sección "Nombre del repositorio", cambiá el nombre (ej.: de "pantallas" a "monitux", y guardá el cambio con el botón "Guardar configuración".

V) Un paso más a realizar en la terminal.

Tu repositorio local aún seguirá apuntando a la URL anterior, y vas a necesitar actualizar esa referencia con la nueva URL:

git remote set-url origin https://codeberg.org/entropiabinaria/monitux.git

De este modo, la próxima vez que hagas "git pull" o "git push", estos procedimientos apuntarán a esta nueva URL, como debe ser.

¡Listo! ¡Disfrutá compartiendo tu conocimiento!

Edición manual de entradas en GRUB2 para UEFI-GPT y MBR-DOS

                     (P) Hugo Napoli, 2017                   


* * * MBR-DOS * * *

Edición manual de entradas en GRUB2 (guía rápida "paso a paso").

 1. Abrir el navegador de archivos "Dolphin" como superusuario, ejecutando en la terminal el comando sudo dolphin y navegá hasta el archivo "grub.cfg" dentro de /boot/grub2/

Si usás otro navegador de archivos como Thunar, hacé lo mismo (sudo thunar).

 2. Abrir "grub.cfg" (se puede utilizar KWrite o cualquier editor de texto simple para esto), y copiar todo lo que haya entre:

### BEGIN /etc/grub.d/30_os-prober ###

y

### END /etc/grub.d/30_os-prober ###
NOTA: se puede utilizar cualquier editor de estas características: lo importante es que este no añada "formato oculto" (tal como los procesadores de texto como Writer), y que sea un editor de texto plano (gedit, kate, kwrite, incluso nano u otros editores de texto para terminal).

En este caso, la información a copiar, sería la siguiente:

menuentry 'Windows 7 (loader) (en /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-chain-0C608BFB608BE9B2' {
    insmod part_msdos
    insmod ntfs
    set root='hd0,msdos1'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  0C608BFB608BE9B2
    else
      search --no-floppy --fs-uuid --set=root 0C608BFB608BE9B2
    fi
    chainloader +1
}
menuentry 'Windows 7 (loader) (en /dev/sda4)' --class windows --class os $menuentry_id_option 'osprober-chain-D92D-3233' {
    insmod part_msdos
    insmod fat
    set root='hd0,msdos4'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos4 --hint-efi=hd0,msdos4 --hint-baremetal=ahci0,msdos4 --hint='hd0,msdos4'  D92D-3233
    else
      search --no-floppy --fs-uuid --set=root D92D-3233
    fi
    chainloader +1
}

 3. Navegar hasta /etc/grub.d/ y abrir el archivo 40_custom
Pegar, a continuación de las líneas

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

la información copiada anteriormente desde el archivo "grub.cfg".

 4. Editar únicamente los nombres de este tipo, escribiendo solamente dentro de las comillas simples (no tiene por qué respetarse la misma cantidad de caracteres preexistente):

'Windows 7 loader (en /dev/sda4)'

Ejemplo:

'Sistema Operativo Windows 7'

En este ejemplo, son 2 entradas del estilo 'Windows 7 loader (etc.)', por lo tanto, pueden ser editadas ambas.

 5. Guardar los cambios en 40_custom

 6. Abrir una consola como superusuario y ejecutar la siguiente orden:

grub2-mkconfig -o /boot/grub2/grub.cfg

NOTA: el comando "grub2-mkconfig -o /boot/grub2/grub.cfg" es correcto para openSUSE y otros sistemas que utilicen esta ruta. Sin embargo, en otras distribuciones (como Debian/Artch, etc), la ruta común puede ser otra (por ejemplo "/boot/grub/grub.cfg") y el comando podría ser simplemente "update-grub" (el cual es un script que ejecuta grub-mkconfig con los parámetros adecuados) o "grub-mkconfig -o /boot/grub/grub.cfg".

 7. Abrir la herramienta gráfica de configuración de GRUB2 (llamada "Cargador de arranque", en OpenSuse).
Desmarcar la opción -dentro de Bootloader Options- de "Sondear sistema operativo extra".
Esto hará que las entradas de Windows -y de otros sistemas operativos que puedan existir -incluyendo otros sistemas Linux-, desaparezcan, quedando únicamente la/s que hayamos introducido de manera manual.
Pulsar el botón Aceptar, y esperar a que termine todo el proceso (unos 30 segundos, posiblemente).

NOTA: el nombre "Cargador de arranque" es el indicado en en openSUSE. Para otras distribuciones, podría no existir una herramienta gráfica (o tener esta un nombre diferente), y se necesitaría un "enfoque más manual" (basado en terminal) para deshabilitar la opción de "Sondear sistema operativo extra" si no se utiliza os-prober.
Existe una gran herramienta llamada "grub customizer" que puedes probar antes de "meter mano" en la terminal.

 OPCIONAL: Abrir la herramienta gráfica de configuración de grub2, nuevamente, y seleccionar la entrada predeterminada, de no ser esta OpenSuse.

En la siguiente imagen, pueden identificarse claramente estos 2 últimos pasos.


NOTA IMPORTANTE: Se puede generar una imagen ISO arrancable de grub2, con las configuraciones personalizadas que hayamos realizado, mediante el siguiente comando:

grub2-mkrescue -o ruta_completa_al_archivo.iso iso

NOTA: tené en mente que la palabra "iso", al final de la orden, no debe ser interpretada como parte de la ruta en sí, sino como un argumento para el comando. Esto puede que se preste para la confusión.
 
* * * GPT-UEFI * * * 

Si tu sistema utiliza el modo de arranque UEFI y el esquema de particiones GPT (lo cual es lo más común en ordenadores modernos), los pasos fundamentales para la edición manual de entradas en GRUB2 siguen siendo los mismos, pero el contenido de las entradas a copiar y algunos detalles menores varían.

Las principales diferencias a tener en cuenta son las siguientes.

Módulo de partición:

en lugar de insmod part_msdos (para MBR), verás insmod part_gpt. Esto indica que GRUB está manejando una tabla de particiones GPT.

Identificación de la partición:

En lugar de set root='hd0,msdosX' (donde X es el número de la partición MBR), verás set root='hd0,gptX' (donde X es el número de la partición GPT).

Carga del sistema operativo (especialmente Windows):

la línea "chainloader +1" que se utiliza para cargar el sector de arranque de un sistema MBR, cambia radicalmente para UEFI.
Para cargar Windows en un sistema UEFI, GRUB no "carga el sector de arranque", sino que apunta directamente al ejecutable EFI del gestor de arranque de Windows, que suele estar en la partición del sistema EFI (ESP).
Una entrada típica para Windows en UEFI luciría algo así:

        menuentry 'Windows Boot Manager (en /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-efi-0C608BFB608BE9B2' {
            insmod part_gpt
            insmod fat
            set root='hd0,gpt1' # O la partición GPT en donde esté la ESP de Windows.
            if [ x$feature_platform_search_hint = xy ]; then
              search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  0C608BFB608BE9B2
            else
              search --no-floppy --fs-uuid --set=root 0C608BFB608BE9B2
            fi
            chainloader /EFI/Microsoft/Boot/bootmgfw.efi # Esta es la clave para UEFI
        }

Observá la línea "chainloader /EFI/Microsoft/Boot/bootmgfw.efi". Esta ruta especifica la ubicación del cargador de arranque de Windows dentro de la partición ESP. La UUID en la línea search --fs-uuid corresponderá a la UUID de la partición del sistema EFI (ESP) donde se encuentra "bootmgfw.efi".

Ubicación de "grub.cfg" y "40_custom":

las ubicaciones de los archivos principales de configuración de GRUB2 (/boot/grub2/grub.cfg o /boot/grub/grub.cfg y /etc/grub.d/40_custom) generalmente no cambian. Estos archivos residen en tu partición Linux. Lo que GRUB2 carga desde la partición EFI, es una "pequeña parte" que le indica dónde encontrar el resto de su configuración.

Herramienta gráfica (paso 7):

la opción de "Sondear sistema operativo extra" sigue siendo relevante y funciona de la misma manera para evitar que "os-prober" (el programa que detecta a otros sistemas) añada automáticamente las entradas, independientemente de si estás en BIOS o UEFI.

Resumen de la adaptación:

para un sistema UEFI-GPT, el procedimiento es idéntico al descrito en los 7 pasos, pero al momento de copiar la información del grub.cfg (paso 2), notarás que las entradas de otros sistemas operativos (como Windows) detectados por os-prober tendrán la sintaxis part_gpt y chainloader /EFI/... en lugar de part_msdos y chainloader +1. Es de vital importancia copiar estas líneas específicas para UEFI.

Una vez completados estos pasos, habrás logrado personalizar tus entradas de Grub2 de forma manual, dándote un control preciso sobre el orden y la visibilidad de tus sistemas operativos al iniciar. Este método es especialmente útil para aquellos que buscan una configuración más estática y confiable, evitando que futuras actualizaciones del sistema sobrescriban sus preferencias de arranque. Recordá que es bueno siempre realizar una copia de seguridad de tus archivos de configuración antes de hacer cambios importantes en ellos. Con esta guía, tienes el poder de adaptar el arranque de tu sistema a tus necesidades.

Artículo escrito en el año 2017 y revisado, ampliado y adaptado en julio de 2025.
Flag Counter Visitas previas a la existencia de este contador: 3433

Artículos aleatorios

    Páginas: