Por que pico-xbar
Pico-xbar fue un proyecto de fin de semana... uno de esos proyectos "de fin de semana" que se extienden por varias semanas. Esos en los que uno no puede dejar de trabajar hasta que quedan terminados. Resultó ser el primero (junto con PicoJSX) de mis proyectos hobby que marqué como "público" en mi perfil de Github después de que decidí compartir un poco más de lo que hago.
La razón de ser del experimento de pico-xbar es que recientemente actualicé mi macbook por una con 64GB de memoria compartida. Quizá ya no sea mucho para estándares actuales, pero el brinco desde los 16GB de mi vieja macbook se siente y mucho. Y mientras más RAM tiene uno, mas celoso se vuelve con su uso. Me pasó a mi. Me vi constantemente revisando que aplicaciones consumen mas memoria, maldiciendo a Google Chrome, minimizando el uso de aplicaciones creadas con Electron y prefiriendo apps nativas. Todo para mantener el uso de memoria en el mínimo posible, un sinsentido. Por ahí va la cosa, en cuanto a pico-xbar.
He sido usuario de xbar por años. Me volví adicto una vez que, tratando de evitar usar aplicaciones como Local by Flywheel, instalé todo el stack necesario para desarrollo WordPress utilizando homebrew. Bastó un script de xbar personalizado para tener en la barra menú de macOS un ícono que al presionarlo me mostraba opciones para seleccionar una versión distinta de PHP o apagar/encender Apache, MariaDB o XDebug. Más recientemente, lo uso para mostrar un ícono que indica el estado actual de las teclas multimedia del teclado de la Mac, ya que constantemente las configuro para que funcionen como teclas de función para ciertas herramientas en la terminal, pero vuelvo a su uso regular cuando quiero escuchar música, por ejemplo.
Entonces, durante mi paranoia por el consumo de memoria, me di cuenta de que xbar consumía mucha, muchísima memoria para ser solamente una app que muestra un menú en la barra del sistema y nada mas. Un vistazo al monitor de actividad en macOS fue suficiente para conocer la razón, pues filtrando la lista de procesos por "xbar" arrojaba 4 procesos con nombres muy característicos de las aplicaciones que usan tecnologías web para su interfaz gráfica. Pero, que interfaz gráfica tiene xbar? el "Plugin Browser". Una ventana que solo abres una vez en la vida, estaba usando un buen trozo de memoria todo el tiempo. "Hay que eliminar esa ventana. Es open source, y es un buen pretexto para escribir algo de Go", pensé, y me puse manos a la obra, creyendo que sería solo cuestión de remover alguna referencia aquí y allá y que en unas horas tendría una versión más eficiente.
Ciertamente, fue buena práctica. No solo de Go, sino de Objective-C y AppKit, tecnologías que no usaba desde mis tiempos en Teknol, allá cuando ARC era una novedad. Esto fue así por que xbar esta hecho con Wails, que no es otra cosa mas que un Electron mas especializado para usar Go como backend, en lugar de Node, y no era posible simplemente "extirpar" wails, sino todo lo contrario: extirpar el código útil y re-implementarlo en una app sin Wails. Wails tiene un API muy flexible para crear cualquier cantidad de elementos en la barra de menus de macOS y actualizar constantemente su contenido, cosa que no me fue posible reproducir con ninguno de los módulos populares que ya existen en Go y por eso terminé ensuciándome un poco las manos.
Al final todo valió la pena y tengo mi propio xbar que no solo es más eficiente, sino que además actualiza el contenido de los menús incluso cuando están desplegados. Elegí el prefijo "pico" por obvias razones: siendo "pico" mas pequeño que el "nano" que tradicionalmente se usa para denotar cosas pequeñas. También lo hice para alinearlo con PicoJSX, PicoTap y PicoGap, que son otros de mis proyectos bebé.