Cómo saber si es un bug el no encontrar una aplicación en el menú

• Estilos de menú
• Entradas de menú ocultas
• Buscar ficheros desktop
• Cuando no hay ficheros desktop
• Cuando hay varios ficheros desktop
• Cuando hay un único fichero desktop
• Reportando bugs

En ocasiones nos encontramos con que instalamos una aplicación, y no aparece ninguna entrada en el menú para ellas. ¿Por qué ocurre esto? ¿Es un comportamiento lógico? ¿Es un bug? A continuación, una pequeña explicación para que quienes se encuentren con este problema sepan qué es lo que deben hacer.

Primero de todo, una pequeña introducción sobre los sistemas de menús. Hasta Mandriva 2006, se utilizaba el sistema de menús de Debian, que permitía lidiar de forma homogénea con los distintos formatos de menús utilizados por cada escritorio. Desde Mandriva 2007 en adelante, se migró del antiguo sistema de menús a Desktop Menu Specification, el estándar de freedesktop.org.

Tanto KDE como GNOME como XFCE soportan el sistema de menús XDG (The X Desktop Group, nombre antiguo de freedesktop.org, pero que sigue usándose para algunas cosas como acortar nombres ;) ), además de mantener compatibilidad con sus antiguos sistemas de menús. Desconozco la compatibilidad de otros escritorios con el sistema de menús XDG. Para información más detallada sobre el sistema de menús, consultar el wiki de Mandriva: Development/Howto/XDGMenuSystem.

Terminada la breve introducción, pasemos a ver los posibles problemas por los que una aplicación puede no aparecer en el menú y sus soluciones.

Estilos de menú

Primeramente, hay que considerar el estilo de menú de Mandriva, ya que según el estilo algunas aplicaciones podrían no mostrarse. Pueden escogerse 3 tipos de menú, a saber:

• menú original de KDE/GNOME
• menú Discovery
• menú de Mandriva

Para escoger el estilo de menú se puede hacer desde consola utilizando drakmenustyle, o desde el propio menú (la ubicación de la entrada dependerá, lógicamente, del estilo de menú que se esté usando). Los estilos pueden establecerse independientemente para cada usuario, o de forma global para el sistema (si se ejecuta desde consola como root, o bien desde el Centro de control de Mandriva (drakconf)).

En el menú original de cada escritorio podrían no aparecer todas las aplicaciones. El motivo, si no me equivoco, es que, aunque ambos utilizan el sistema de menús de freedesktop.org y también tienen soporte para la versión antigua de su sistema de menús, para lo que no tienen soporte es para la versión del sistema de menús antigua cada uno del otro. Es decir, KDE no ve las aplicaciones que usan el sistema de menús antiguo de GNOME, y viceversa (repito que no estoy seguro 100% de esto).

Pero, ¿no se supone que Mandriva había migrado al sistema de menús de freedesktop.org? Sí, y no. La mayor parte de los paquetes están migrados al nuevo sistema de menús. Peeero... en toda migración quedan flecos y cosas que pulir ;) Por tanto, puede darse el caso de que si estás utilizando uno de los estilos de menú nativos, no veas aplicaciones que sí verías con otros estilos. No obstante, como veremos más adelante podemos considerar esto un bug de la aplicación.

El estilo de menú Discovery por su parte es una versión reducida del menú que incluye las aplicaciones más comunes. Si no me equivoco, no se muestran todas las aplicaciones, aunque en este caso sí es deliberado.

Finalmente, queda el estilo de menú Mandriva (mi preferido, y francamente una de las cosas que más me gustan de Mandriva). El estilo de menú de Mandriva muestra tanto aplicaciones que usan el sistema de menús de freedesktop.org, como las que usan el de KDE, como las que usan el de GNOME (y supongo que también tiene soporte para los demás tipos de menús, que seguramente alguno más habrá). Por tanto, a la hora de investigar posibles problemas con el sistema de menús, lo mejor es utilizar este estilo.

Entradas de menú ocultas

Si una vez que tenemos configurado el estilo de menú de Mandriva la aplicación que queremos sigue sin aparecer, puede ser sencillamente porque la entrada de dicha aplicación está oculta.

¿Y cómo puedo saber si está oculta? No sé si hay alguna forma más sencilla para hacer esto, pero la que yo conozco es comprobando los ficheros desktop. Los ficheros .desktop son una especificación de freedesktop.org que permite describir cómo se deben lanzar las aplicaciones, cómo se muestran en el menú, su icono...

El formato del fichero desktop es muy sencillo, formado simplemente por una serie de propiedades y un valor asignado:

propiedad1=valor1
propiedad2=valor2
...

Una de las propiedades disponibles es Hidden. Si el valor de esta propiedad es true, la entrada del menú estará oculta.

Del mismo modo, también existe la propiedad OnlyShowIn, que indica en qué escritorios debe mostrarse la entrada del menú. Desde cualquier otro escritorio no incluido en sus valores, la entrada estará oculta.

En estos dos últimos casos cabe plantearse si esas propiedades son correctas, o si están de más y se trata de un bug.

Y lógicamente, otro motivo por el que una aplicación no se muestra en el menú es porque es una aplicación de consola (aunque algunas también pueden mostrarse haciendo que se lance una consola cuando se ejecutan).

Buscar ficheros desktop

En el apartado anterior consideré que se miraba en el fichero .desktop de la aplicación las propiedades para saber si tienen un valor correcto. Pero, ¿cómo puedo saber dónde están los ficheros desktop de la aplicación?

Los ficheros desktop vienen incluidos en los paquetes que contienen las aplicaciones. Así que la forma más fácil de buscar un fichero .desktop es buscarlo utilizando desde una consola el práctico urpmq combinado con el no menos útil grep. Pero vayamos poco a poco, ¿qué es cada cosa y cómo me pueden servir para buscar archivos .desktop en paquetes?

urpmq es un complemento de urpmi que permite buscar en la base de datos de paquetes de éste, y mostrar información de los paquetes. Y entre sus múltiples posibilidades, está la de mostrar la lista de ficheros que forman un paquete. Para ello, tenemos que hacer urpmq -l nombrePaquete-version. Utilizo nombrePaquete-version en lugar de nombrePaquete a secas ya que si hay más de un paquete con el mismo nombre (por ejemplo, debido a actualizaciones o backports), mostraría los paquetes de todas las versiones.

Hay que tener en cuenta que esto funciona sólo cuando se usan ficheros hdlist (que contienen toda la información de un repositorio), pero no con los synthesis (que sólo contienen información de dependencias, por lo que son mucho más pequeños pero también pierden funcionalidad).

Por su parte, grep permite buscar una cadena dentro de un texto y mostrarla. Dado que urpmq -l nombrePaquete-version muestra todos los ficheros de un paquete, y sólo nos interesan los .desktop, redirigimos la salida de urpmq a grep mediante una tubería de la siguiente manera:

urpmq -l nombrePaquete-version | grep .desktop

Según la salida que nos muestre, nos encontraremos ante un caso u otro.

Cuando no hay ficheros desktop

Un caso no muy común, pero que puede ocurrir (sobretodo con aplicaciones que no son de un escritorio concreto, como por ejemplo juegos) es que el paquete no tenga ningún fichero desktop. En este caso generalmente podemos considerar que nos encontramos ante un bug tanto de la aplicación del paquete en sí, como de Mandriva.

En los casos en los que una aplicación carece de fichero desktop, Mandriva suele añadir un fichero desktop específico que permite a la aplicación mostrarse en el menú. Ejemplos de esto pueden verse en /usr/share/applications. Los archivos desktop que comienzan por mandriva- son específicos de la distribución y no están en el paquete original (como por ejemplo pasa con foobillard).

Si una aplicación que debería aparecer en el menú no tiene fichero desktop de ningún tipo, y por tanto no aparece en el menú, es un bug de Mandriva por no haber añadido un fichero desktop específico.

Pero también es un bug del propio programa, ya que lo lógico es que todos los programas migren al sistema de ficheros desktop de freedesktop.org, independientemente de si son de un escritorio, otro, o ninguno en concreto.

Cuando hay varios ficheros desktop

Puede darse el caso de que un paquete tenga más de un fichero desktop, ya que estos se utilizan para más cosas que para entradas de menú. Por ejemplo, los KParts de KDE (la tecnología que permite incrustar componentes, por poner un ejemplo para ver imágenes directamente en Konqueror sin abrir un programa externo) tienen ficheros desktop propios.

¿Cómo discernir la paja del grano? Siendo breves, los únicos que nos interesan son aquellos que estén en los siguientes directorios (y sus subdirectorios):

• /usr/share/applications/: sistema de menús de freedesktop.org
• /usr/share/applnk/: sistema de menús de KDE
• /usr/share/gnome/apps/: sistema de menús de GNOME

En esencia, podemos ignorar los demás ficheros desktop para el propósito que nos ocupa, que es encontrar fallos a la hora de mostrar aplicaciones en el menú.

Al igual que en el caso anterior, tampoco es muy común que, una vez hecha la criba, tengamos más de un fichero desktop relevante. Pero puede darse el caso, y que ninguna entrada se muestre en el menú, como por ejemplo pasa con el paquete para KDissert.

El paquete contiene un fichero desktop en /usr/share/applications/kde/ y otro en /usr/share/applnk/Utilites/. El problema es que no son iguales, sino que el segundo fichero contiene una categoría de Mandriva adicional a las que contiene el primero (en el siguiente apartado se verán más a fondo las categorías).

Parece ser que, al ser distintas las categorías para una misma aplicación, el pobre sistema de menús se trastorna y no muestra ninguna entrada. La solución es simple: añadir la categoría de Mandriva adicional también en el primer fichero desktop, de forma que ambos archivos sean iguales.

En este caso, en el que la categoría adicional es de Mandriva, nos encontramos con un bug puramente de Mandriva (ya que la modificación de los ficheros desktop fue cosa de Mandriva). En el caso de KDissert, es el siguiente: KDissert isn't shown in KDE menu.

El hecho de que el paquete original tenga dos ficheros desktop puede verse también como un bug, ya que lo correcto sería seguir únicamente una especificación. No obstante, esto puede deberse a cuestiones como la compatibilidad hacia atrás con versiones más antiguas de KDE.

Cuando hay un único fichero desktop

Ánimo, que ya estamos acabando ;)

Cuando nos encontramos con un único fichero desktop, pueden ocurrir dos cosas: que esté en el directorio o subdirectorios del menú de freedesktop.org (/usr/share/applications) o no.

Si no está en dicho directorio, es un bug de la aplicación, por lo mismo que ocurría cuando no había ningún fichero desktop: las aplicaciones deberían seguir el estándar de freedesktop.org. También es conveniente enviar un bug a Mandriva con el fin de que realicen una versión actualizada del paquete que corrija el problema mientras sale la nueva versión de la aplicación.

Esto podría ser la causa de no ver algunas aplicaciones si se utiliza el estilo de menú de KDE o de GNOME. No obstante, cuando se utiliza el estilo de menú de Mandriva, la causa es otra (ya que, recordemos, el estilo de menú de Mandriva soportaba los directorios del sistema de menú de freedesktop.org, de KDE y de GNOME).

Llegados a este punto, la única causa restante del problema serían (tanto para ficheros desktop en /usr/share/applications como en los directorios de KDE y GNOME) las categorías del fichero desktop.

¿Y qué son las categorías? Ni más ni menos que el tipo de aplicación: juego, multimedia, administración... Existen una serie de categorías generales, y una serie de categorías adicionales que complementan a las generales. Además, existen categorías específicas, como X-KDE-More o X-MandrivaLinux-MoreApplications-Games-Strategy.

Según las categorías a las que pertenece un fichero desktop, la entrada se muestra en el menú en un lugar o en otro (se puede cambiar qué categorías están asociadas a qué estructura del menú, pero está fuera del ámbito de este documento, aparte de que no domino el tema ;) ).

El problema surge cuando las categorías incluidas en el fichero no son válidas (por ejemplo, Wrong category in desktop file prevents trackballs from showing in the menu), tienen un formato inválido (por ejemplo, falta el ; tras la última categoría, o están mal escritas: Mispelled Mandriva category in desktop file prevents knotes from showing in the menu) o simplemente no hay sección de categorías (por ejemplo, TEG doesn't show in KDE menu o Missed category in desktop file).

En todos estos casos debe informarse a Mandriva del problema, y en algunos casos también a los desarrolladores de la aplicación implicada (cuando en el sistema de control de versiones o en el paquete de código fuente de la aplicación el fichero desktop contenga fallos en las categorías).

Reportando bugs

Finalmente y para terminar, hay que tener en cuenta que los bugs encontrados es muy importante que sean reportados, ya que si no se informa de ellos, no serán arreglados ;) Además, es una forma sencilla y práctica de colaborar con el software libre :)

Para más información sobre cómo enviar bugs en Mandriva, lee ¿Encontraste un error en Mandriva? Utiliza Bugzilla / Drakbug para comunicarlo. Para enviar bugs a programas concretos, dependerá del programa en cuestión, así que lo mejor que puedes hacer es visitar la página web y buscar por ahí.

En caso de que el inglés sea un problema, siempre puedes comentarlo en el foro de bugs, y fijo que alguien te podrá echar una mano con el idioma.