{"id":2233,"date":"2019-09-20T23:20:35","date_gmt":"2019-09-20T23:20:35","guid":{"rendered":"http:\/\/blog.rastersoft.com\/?p=2233"},"modified":"2019-09-20T23:20:35","modified_gmt":"2019-09-20T23:20:35","slug":"desktop-icons-gnome-shell-y-wayland","status":"publish","type":"post","link":"https:\/\/blog.rastersoft.com\/?p=2233","title":{"rendered":"Desktop icons, Gnome shell y Wayland"},"content":{"rendered":"\n

Hace cosa de un a\u00f1o y medio la gente de Gnome anunci\u00f3<\/a> que eliminaba de Nautilus<\/a> todo el c\u00f3digo que pintaba los iconos de escritorio. Para los que no se quieran leer el tocho, resumir\u00e9 r\u00e1pidamente que el motivo era, b\u00e1sicamente, que dicho c\u00f3digo ven\u00eda de muchos a\u00f1os atr\u00e1s, era extremadamente complejo debido a las limitaciones de las versiones antiguas de GTK, y cada vez era m\u00e1s dif\u00edcil de mantener a la vez que se a\u00f1ad\u00edan nuevas caracter\u00edsticas al resto de Nautilus. Adem\u00e1s, hac\u00eda ya seis a\u00f1os que Gnome 3 no utilizaba iconos de escritorio. Por si fuera poco, ten\u00eda muchos bugs de dif\u00edcil soluci\u00f3n (por ejemplo, el soporte multimonitor no funcionaba demasiado bien). Y a todo esto hab\u00eda que sumar el hecho de que en Wayland<\/a> no funcionar\u00eda correctamente debido a las limitaciones que impone en aras de la seguridad: en efecto, en Wayland una aplicaci\u00f3n no puede decidir donde colocar una ventana ni mantenerla fija en el fondo, entre otras cosas. El motivo de esta limitaci\u00f3n es evitar que una aplicaci\u00f3n maliciosa pueda hacerse pasar, por ejemplo, por el escritorio, o por una barra de tareas, etc, poniendo en riesgo la seguridad del sistema. Por desgracia, esto tambi\u00e9n significa que, en Wayland, cosas como las barras del escritorio, un dock o los iconos de escritorio no se pueden delegar en una aplicaci\u00f3n, sino que tienen que ser manejadas desde dentro del gestor de ventanas. Es por esto que se cre\u00f3 la extensi\u00f3n de Gnome Shell llamada Desktop Icons<\/a>: para seguir ofreciendo iconos en el escritorio en Gnome Shell para aquellos que lo deseasen (como yo).<\/p>\n\n\n\n

La versi\u00f3n disponible en aquel momento ya implementaba la funcionalidad m\u00e1s b\u00e1sica, pero ten\u00eda un defecto que, para m\u00ed, era muy grave: no permit\u00eda utilizar una \u00fanica pulsaci\u00f3n para lanzar un icono, sino que obligaba a utilizar doble click. Como yo estoy acostumbrado a la primera manera, me li\u00e9 la manta a la cabeza y envi\u00e9 un parche para implementarlo. Tras muchos cambios para adecuar el estilo de c\u00f3digo al que se utiliza en el proyecto Gnome y m\u00e1s cosas (nunca podr\u00e9 agradecer lo suficiente a Carlos Soriano su infinita paciencia ense\u00f1\u00e1ndome a manejar Git en condiciones), lo aprobaron. Y le cog\u00ed el gustillo, con lo que detr\u00e1s de \u00e9l vino otro, y otro, y otro m\u00e1s… Hasta que, recientemente, me ofrecieron ser el mantenedor del c\u00f3digo (lo que para m\u00ed es un honor, todo sea dicho).<\/p>\n\n\n\n

Un a\u00f1o despu\u00e9s, la extensi\u00f3n ya incorpora todo lo que se pretend\u00eda para la versi\u00f3n 1.0<\/a> y m\u00e1s, y se incluye por defecto en la versi\u00f3n de Gnome Shell de Ubuntu, y no puedo menos que agradecer a toda la gente que ha colaborado con parches e informes de bugs.<\/p>\n\n\n\n

Por desgracia, a medida que m\u00e1s y m\u00e1s usuarios la han ido instalando, han ido surgiendo algunos problemas inherentes al hecho de que sea una extensi\u00f3n, problemas que no eran nada evidentes al principio y que s\u00f3lo se han ido haciendo visibles a medida que la cantidad de usuarios crec\u00eda.<\/p>\n\n\n\n

El primer gran problema es que todas las extensiones se ejecutan en el mismo bucle principal que el compositor de ventanas. Esto significa que una extensi\u00f3n que necesite mucho tiempo para ejecutar una operaci\u00f3n puede, literalmente, congelar todo el escritorio, incluyendo el mism\u00edsimo repintado de todas las ventanas. En el caso de extensiones \u00abnormales\u00bb, que se limiten a mostrar un icono en la barra de tareas o as\u00ed, esto no es un problema, porque el trabajo que realizan es m\u00ednimo; sin embargo, en el caso de Desktop Icons s\u00ed lo es, pues cada vez que tiene que refrescar el escritorio (por ejemplo porque se a\u00f1ade o borra un fichero), tarda en torno a medio segundo en realizar todas las operaciones (leer la lista de ficheros en el directorio, obtener sus metadatos, generar los pixmaps, eliminar las cuadr\u00edculas e iconos previos, generar una nueva cuadr\u00edcula, crear los nuevos iconos, y pintarlos en su sitio), y durante ese tiempo todo el escritorio se congela. Obviamente, por que ocurra una vez cada mucho no es muy problem\u00e1tico, pero sin duda es molesto para el usuario.<\/p>\n\n\n\n

Solucionar esto, aunque no es totalmente imposible, no resulta sencillo: actualmente ya utilizamos funciones as\u00edncronas en todos los sitios posibles para evitar bloquear la cola de eventos, pero no es suficiente. Adem\u00e1s ser\u00eda necesario evitar repintar todo el escritorio y sus elementos, y s\u00f3lo a\u00f1adir o quitar los iconos de los ficheros que se hayan a\u00f1adido o eliminado. Pese a todo, esto s\u00f3lo reducir\u00eda un poco m\u00e1s el problema, pero no lo resolver\u00eda del todo, pues si un programa a\u00f1ade y borra constantemente un fichero al escritorio, por ejemplo, puede a\u00fan bloquear la cola, en buena medida porque algunas operaciones de repintado se realizan s\u00f3lo cuando ya no quedan operaciones pendientes en la cola de eventos. Adem\u00e1s, implementar esto implicar\u00eda un importante redise\u00f1o interno, y teniendo en cuenta que algunas distribuciones cuentan con Desktop Icons para sus versiones de soporte a largo plazo, no es algo que se pueda hacer de cualquier manera, sino que debe implementarse de manera muy progresiva y con una buena revisi\u00f3n por pares de todos y cada uno de los parches, para garantizar que no hay errores ni regresiones.<\/p>\n\n\n\n

Otro problema es la imposibilidad (al menos actualmente) de integrar Drag’n’Drop<\/a> al completo: aunque dentro de Gnome Shell existe soporte de Drag’n’Drop, no es compatible con operaciones desde el \u00abespacio de usuario\u00bb; esto es: una aplicaci\u00f3n no puede ni enviar al compositor, ni recibir de \u00e9l, eventos de Drag’n’Drop . Aunque en principio ser\u00eda posible implementar dicha comunicaci\u00f3n, no es una tarea trivial, y de hecho, tras tantear a alg\u00fan programador de Mutter, la conclusi\u00f3n es que es lo suficientemente complicado como para que s\u00f3lo valga la pena pasar el trabajo de implementarlo en Wayland, pero no en X11.<\/p>\n\n\n\n

Y de aqu\u00ed llegamos al tercer problema: las extensiones se escriben con Clutter<\/a> + St<\/a>, los cuales no funcionan exactamente igual que Gtk<\/a>. Un ejemplo es la forma en que se procesan los eventos de enter_notify<\/em> y exit_notify<\/em>, que oblig\u00f3 a a\u00f1adir una serie de trucos en el c\u00f3digo que permite seleccionar un grupo de iconos mediante \u00abgoma el\u00e1stica\u00bb, para gestionar correctamente aquellos casos en los que el cursor entraba en una ventana en mitad de una selecci\u00f3n, o cuando pasaba por encima de la barra superior de Gnome. Esto es algo que en Gtk est\u00e1 resuelto desde hace a\u00f1os, gracias al mayor n\u00famero de usuarios y programadores que trabajan con \u00e9l, y que permite detectar m\u00e1s bugs.<\/p>\n\n\n\n

El cuarto problema radica en los cambios entre versiones del escritorio. Dado que Gnome Shell no ofrece una API estable para las extensiones, \u00e9stas tienen que interactuar directamente con el c\u00f3digo interno, por lo que cualquier cambio les puede afectar. En el caso de una extensi\u00f3n tan compleja como Desktop Icons este problema es a\u00fan mayor, hasta el punto de que la actual versi\u00f3n 19.01 ser\u00e1, probablemente, la \u00faltima compatible con Gnome Shell 3.30 y 3.32, y las nuevas versiones necesitar\u00e1n como m\u00ednimo Gnome Shell 3.34.<\/p>\n\n\n\n

A la vista de todos estos problemas, hace un par de meses empec\u00e9 a sopesar la posibilidad de hacer un cambio radical en el dise\u00f1o y mover toda la l\u00f3gica a un proceso independiente del compositor, de manera que toda la gesti\u00f3n de los iconos del escritorio se realice sin interferir con la composici\u00f3n y dem\u00e1s, adem\u00e1s de utilizar Gtk directamente en lugar de St y Clutter. De hecho, cuando se decidi\u00f3 crear la extensi\u00f3n, los autores originales (Carlos Soriano y Ernestas Kulik) sopesaron seriamente esta misma posibilidad, pero lo descartaron precisamente por las limitaciones impuestas por el modelo de seguridad de Wayland, y porque hacerlo dentro de una extensi\u00f3n ten\u00eda m\u00e1s sentido en aquel momento, pues era much\u00edsimo m\u00e1s f\u00e1cil.<\/p>\n\n\n\n

Por supuesto, esto es m\u00e1s sencillo de decir que de hacer, pues, como ya dije antes, aunque en X11 no hay ning\u00fan problema en que una aplicaci\u00f3n mantenga una ventana en el fondo, o que la elimine de la lista de ventanas para que no aparezca al hacer Alt + Tab, en Wayland eso es totalmente imposible por dise\u00f1o. Adem\u00e1s, dado que las extensiones est\u00e1n escritas en Javascript, no es posible lanzar c\u00f3digo en un nuevo thread, y aunque se pudiese, no ser\u00eda posible que dicho c\u00f3digo llamase a funciones de Clutter o St, por lo que hay que descartar la idea de descargar el trabajo en un thread paralelo. Lanzar un proceso independiente s\u00ed es posible, pero \u00e9ste trabajar\u00eda desde fuera del compositor, por lo que, en principio, seguir\u00edamos con el mismo problema.<\/p>\n\n\n\n

Sin embargo, existe una alternativa extra, que es justo la que decid\u00ed investigar, que consiste en repartir el trabajo: por una parte tenemos un programa normal, que trabaja desde fuera del compositor y que utiliza GTK para gestionar absolutamente todo lo relacionado con el escritorio y sus iconos mediante una o varias ventanas normales, exactamente igual a como hac\u00eda el viejo Nautilus en el modo \u00abiconos de escritorio\u00bb; y, por otro lado, una peque\u00f1a extensi\u00f3n cuyo trabajo consiste en lanzar el programa anterior (y relanzarlo cada vez que se muera), detectar la ventana que abre, y asegurarse de que \u00e9sta se mantenga donde debe. De esta manera, el c\u00f3digo dentro de la extensi\u00f3n es m\u00ednimo y se limita exclusivamente a las operaciones que son imposibles de realizar desde el exterior del c\u00f3digo del compositor.<\/p>\n\n\n\n

Por supuesto, es fundamental no romper el modelo de seguridad de Wayland, lo que significa que no se puede permitir bajo ning\u00fan concepto que una aplicaci\u00f3n extra\u00f1a se pueda aprovechar de este mecanismo para colocar su propia ventana como el fondo del escritorio (o como cualquier otro elemento). Para ello, la \u00fanica soluci\u00f3n es que sea la extensi\u00f3n quien lance el proceso, y que cada vez que aparezca una ventana, compruebe si \u00e9sta pertenece al proceso que ella misma ha lanzado, otorg\u00e1ndole esos privilegios exclusivamente en el caso de que as\u00ed sea. Dado que el c\u00f3digo ha sido lanzado espec\u00edficamente por la extensi\u00f3n, se puede considerar que es c\u00f3digo tan confiable como el de dicha extensi\u00f3n (y m\u00e1s si el programa a lanzar forma parte de la propia extensi\u00f3n): si un programa malicioso puede reemplazar el c\u00f3digo de la aplicaci\u00f3n de escritorio, tambi\u00e9n podr\u00eda hacerlo directamente con el c\u00f3digo de la extensi\u00f3n, por lo que el nivel de seguridad es exactamente el mismo.<\/p>\n\n\n\n

Ahora llega la cuesti\u00f3n de c\u00f3mo detectar que una ventana pertenece al proceso lanzado desde la extensi\u00f3n. Mi primera idea fue utilizar metawindow_get_pid()<\/a><\/em> en cada ventana nueva que apareciese, para obtener el PID<\/a> del proceso que cre\u00f3 la ventana y compararlo con el PID del proceso que hemos lanzado desde la extensi\u00f3n; por desgracia, dicha llamada s\u00f3lo funciona en X11 pero no en Wayland, porque utiliza un dato espec\u00edfico de X11. Sin embargo, existe otra llamada, metawindow_get_client_pid()<\/em>, que s\u00ed funciona desde ambos sistemas; por desgracia es privada, lo que significa que s\u00f3lo se puede llamar desde C y desde dentro de mutter<\/em>, nunca desde una extensi\u00f3n escrita en Javascript.<\/p>\n\n\n\n

Propuse entonces en el canal IRC de Gnome Shell que dicha llamada se cambiase a p\u00fablica, pero mi idea no convenci\u00f3 porque existen varios ataques que involucran PIDs de procesos, por lo que, aunque yo hiciese las cosas bien, hacer p\u00fablica dicha llamada podr\u00eda suponer abrir la caja de Pandora. Sin embargo, s\u00ed me redirigieron al c\u00f3digo de XWayland para que viese ah\u00ed como lo hacen<\/a> de manera segura: b\u00e1sicamente, al lanzar el proceso crean manualmente un socket<\/em> y asignan un extremo a Wayland, pasando el otro extremo al proceso hijo para que se comunique a trav\u00e9s de \u00e9l; luego basta con engancharnos a la se\u00f1al map<\/em>() y, por cada ventana que aparezca, comparar si su socket<\/em> coincide con el que creamos nosotros para nuestro proceso hijo, en cuyo caso podemos estar seguros de que esa ventana pertenece a \u00e9l y no a otro.<\/p>\n\n\n\n

La idea era buena, pero por desgracia no se puede implementar directamente en Javascript porque precisa de varias llamadas privadas de mutter<\/em>, adem\u00e1s de que tampoco se pueden crear sockets<\/em> desde Javascript. Ante esto me sugirieron escribir una clase GObject<\/em> que lo implementase y exportase una interfaz para ello, y as\u00ed lo hice: mi primer parche para <\/a>mutter<\/a><\/em> y mi primera clase <\/a>GObject<\/a><\/em>. Esta clase s\u00f3lo funciona con Wayland (para X11 no tiene sentido, pues la propia aplicaci\u00f3n puede detectarlo y hacer ella misma el trabajo), y permite lanzar un proceso y detectar si una ventana concreta pertenece o no a dicho proceso. Si se utiliza desde X11, la parte de lanzar el proceso tambi\u00e9n funciona, pero el m\u00e9todo de detectar si una ventana pertenece o no al proceso genera una excepci\u00f3n (que, obviamente, se puede capturar). Esto permite simplificar el c\u00f3digo en la extensi\u00f3n a la hora de hacer que funcione en ambos entornos de ventanas.<\/p>\n\n\n\n

Aunque dicho parche funciona bien, a\u00fan sigue pendiente de aprobaci\u00f3n; pero yo quer\u00eda poder usar YA<\/strong> la nueva versi\u00f3n de Desktop Icons, as\u00ed que, como a cabez\u00f3n no me gana nadie, decid\u00ed ver qu\u00e9 pod\u00eda hacer para detectar de manera segura la ventana de un proceso utilizando s\u00f3lo lo que ya ten\u00eda disponible en Javascript. Para ello se me ocurri\u00f3 que la aplicaci\u00f3n de escritorio podr\u00eda poner como t\u00edtulo de la ventana una cadena concreta que la extensi\u00f3n pudiese identificar (tiene que ser en el t\u00edtulo, pues no parece haber absolutamente nada m\u00e1s en una ventana que se pueda asignar de manera libre por el programa y que una extensi\u00f3n pueda leer). El problema es que dicha cadena no puede ser predecible, pues entonces otras aplicaciones podr\u00edan hacerse pasar por la leg\u00edtima. Ante esto, decid\u00ed que la extensi\u00f3n generar\u00eda un UUID<\/a> aleatorio de 128 bits justo antes de lanzar el proceso, y se lo pasar\u00eda a \u00e9ste para que lo ponga en el t\u00edtulo de la ventana (y, por supuesto, calculando uno nuevo cada vez que la aplicaci\u00f3n se muera). Pero claro, pasarlo como par\u00e1metro por la l\u00ednea de comandos ser\u00eda completamente inseguro porque cualquier programa puede leer los par\u00e1metros de cualquier otro proceso (basta hacer un ps ax<\/em> o leer \/proc<\/em>), por lo que ten\u00eda que ser algo m\u00e1s seguro. Al final la soluci\u00f3n consisti\u00f3 en pasarlo a trav\u00e9s de stdin<\/em>, de manera que nadie m\u00e1s pueda leerlo (habr\u00eda sido m\u00e1s elegante utilizar un pipe<\/em> espec\u00edfico, pero por desgracia desde Javascript no es posible crear nuevos pipes<\/em>).<\/p>\n\n\n\n

Para simplificar a\u00fan m\u00e1s el c\u00f3digo escrib\u00ed una peque\u00f1a clase Javascript que es compatible a nivel de m\u00e9todos con la clase GObject de mi parche, de manera que, si se aprueba, s\u00f3lo tendr\u00e9 que reemplazar una clase por otra en el c\u00f3digo (o incluso utilizar una u otra en funci\u00f3n de la versi\u00f3n de Gnome Shell).<\/p>\n\n\n\n

Con esto resolv\u00ed el primer problema, pero ahora quedaba el segundo: aunque ya puedo identificar qu\u00e9 ventana es la del escritorio \u00bfcomo hago para mantenerla donde debe estar?<\/p>\n\n\n\n

La soluci\u00f3n elegante ser\u00eda cambiar el tipo de ventana a uno de los tipos est\u00e1ndar<\/a> (en concreto, a META_WINDOW_DESKTOP<\/em>). Por desgracia, desde Javascript no es posible cambiarlo, pues la llamada es privada<\/a>. Obviamente prepar\u00e9 un parche para cambiarlo<\/a>, donde, adem\u00e1s de hacerla p\u00fablica, tambi\u00e9n la renombro para que sea consistente. Este cambio convenci\u00f3 mucho m\u00e1s en el canal IRC, por lo que espero que sea finalmente aceptado junto con el otro, pues la ventaja de estos dos parches es que no son espec\u00edficos para este proyecto, sino que permiten, en general, \u00abexternalizar\u00bb el trabajo que actualmente se realiza dentro del compositor, lo que permitir\u00eda que m\u00e1s elementos, como por ejemplo la barra superior o un dock, puedan ser gestionados desde un proceso externo.<\/p>\n\n\n\n

Sin embargo, segu\u00eda queriendo poder utilizar YA el programa, as\u00ed que lo que hice fue engancharme a varias se\u00f1ales para forzar la ventana a permanecer en su sitio:<\/p>\n\n\n\n