Jugando con DBus en qt
Cuando los usuarios tienen la razón
Hace unos días recibí un mail de un usuario de Kdropbox diciendo que el comportamiento de la aplicación al hacer clic sobre el icono de la bandeja de sistema no era el habitual en KDE. Según me contaba al hacer clic se abría la ventana por tanto al volver a hacerlo debería cerrarse.
Es curioso pero tantos años usando este escritorio y no me había fijado. Lo comprobé y es cierto que no todos los programas lo cumplen, pero aquellos que se distribuyen con KDE sí. Kdropbox abría (y la versión estable la abre aún en el momento de escribir esto) una ventana de un navegador de archivos (dolphin o konqueror) cada vez que se hacía clic en el icono, por lo que era una buena manera de lanzar rápidamente 377 navegadores de archivos, dependiendo de la velocidad de nuestra mano :D
En todo caso terminaba siendo una cuestión de usabilidad y el usuario tenía razón así que había que cambiarlo. Sin embargo había un problema bastante importante en todo esto: hacer un control de ese tipo en una ventana propia de la aplicación hubiera sido relativamente sencillo, pero ¿que pasa si lo que hemos lanzado es un proceso independiente? Bueno, una solución podría ser la primera que se me ocurrió: lanzar el proceso, guardarme el pid y matarlo con el segundo clic. Error, Dolphin no se lanza como instancia nueva si ya está corriendo, o sea que si ya hay una ventana de Dolphin abierta cuando hacemos clic en el icono no tendremos un pid independiente y lo que es peor, matar ese proceso terminaría con todas las ventanas del gestor de archivos que tuviera abiertas el usuario.
Hay que reconocerlo: crear archivos ditribuibles para Linux es un auténtico infierno. Además, como no, seremos víctimas de una nueva lucha de estándares rpm vs deb. Esto hace que sea bastante tentador distribuir simplemente el código fuente y desear suerte a los usuarios con la compilación, aunque de esta manera no llegaremos a los menos aventajados. También es cierto que distribuyendo el fuente no tardarán en aparecer voluntarios que crearán paquetes para determinadas distribuciones pero de esa manera perderemos el control de nuestro software. De modo que, si queremos enfrentarnos a este problema, parece que sólo hay unas pocas soluciones: o bien encontrar un software que nos cree un instalable independiente de la distribución o tratar de llegar a la máxima cantidad de usuarios creando rpms y debs para las mayores distribuciones. Este artículo se centrará en el segundo enfoque.