danirod.es

Como dije en el post anterior (que he partido únicamente para poder enlazarlo aparte), quiero crear un cliente HTTP gráfico. «Como Postman, pero libre. Como ThunderClient, pero sin exigirme abrir un editor de textos para usar el plugin».

En primer lugar, voy a evaluar y determinar el stack tecnológico con el que voy a trabajar, y luego las características que quiero que tenga. Spoiler: GTK y Rust. Sin embargo, en este post voy a intentar justificar el por qué de estas decisiones.

Stack tecnológico

Dadas las restricciones y los requisitos que quiero que cumpla (visual, nativo, libre y multiplataforma), he considerado que aunque admito que sé que no es agradable de programar o de diseñar, la mejor opción es GTK+. Qt es una alternativa muy popular a GTK+, pero tengo la ventaja de que en realidad ya sé cómo funciona el modelo de programación en GTK+, por lo que iré más rápido. Además, Qt ha tenido varias veces a lo largo de su historia algunos romances peculiares con el mundo privativo que hacen que desconfíe un poco.

Ahora: ¿lenguaje de programación? GTK+ tiene varios bindings oficiales que permiten usar la biblioteca desde diversos lenguajes de programación. Existen más bindings no oficiales, y también bindings que han caído en el olvido, pero vamos a descartar cualquier lenguaje que no esté en este momento en el manual de desarrollo de GTK.

Vamos a primero listar los lenguajes en los que NO lo voy a hacer:

• C: Es mi lenguaje de programación favorito, y sería divertido pero… no es este el tipo de proyecto donde creo que le favorezca.
• C++: No sé programar C++, así que lo descartamos por ahora.
• JavaScript: Lo que GTK+ llama JavaScript es el entorno de ejecución GJS, que no NodeJS, por lo que hacerlo multiplataforma sería complicado.
• Python: También es tentador porque permitiría hacer un MVP rápido, porque es ágil de modificar y ejecutar. Sin embargo, de cara a hacer la aplicación multiplataforma, preferiría no tener que instalar todo un entorno de ejecución en Windows para lanzar el programa.

Mención especial para Vala. Me parece un lenguaje muy elegante y que toma mucho de los principios de C#, motivo por el cual no quería ponerlo junto a lo que parece la lista de descartes y de juguetes feos. Sin embargo, no tengo confirmada su compatibilidad con Windows y veo un poco limitadas las herramientas de desarrollo en comparación con cómo eran las cosas hace 10 años, por lo que no soy optimista.

Me llama la atención que, por primera vez, el manual admita la existencia de bindings para Go. Go es uno de mis lenguajes favoritos también y no me molestaría hacerlo con Go. Sin embargo, no conozco muchas aplicaciones de GTK hechas en Go (ni siquiera veo Go en el filtro de lenguajes de gitlab.gnome.org), y no quiero trabajar con algo tan novel.

Así que me queda la opción que ahora mismo creo que me va a aportar un buen balance en seguridad, compatibilidad y ecosistema, que es Rust y gtk-rs. Rust no me desagrada pero tampoco es mi lenguaje de programación favorito. Es un lenguaje que veo muy verboso para escribir cualquier tipo de programa mínimo, y con un ecosistema de paquetes detestable donde parece que no importa terminar un programa si por lo menos dejas un código inteligente por el camino. Pero sin embargo, marca todos los checks por el camino, así que tampoco quiero anteponer mis opiniones subjetivas y personales a lo que creo que sería una decisión que le encaje bien al proyecto. Por este motivo, adelante.

Blueprint

Tradicionalmente, para hacer aplicaciones en GTK, tenías dos opciones:

• La programática, que consiste en escribir cada botón, cada label, cada ventana, con código fuente, algo que aunque es muy flexible, también vuelve mantener la interfaz gráfica muy aburrida de mantener.
• GtkBuilder y XML. Con un programa como Glade se fabrica un archivo XML que describe la interfaz de usuario, al estilo XAML o QML, y desde el código fuente se carga esa descripción de la interfaz, se le agregan los callbacks, y se pinta.

Una tercera forma que está ahora mismo en construcción es Blueprint. Es una herramienta experimental para fabricar interfaces de usuario GTK sin tener que escribir XML.

La idea es que en vez de escribir archivos XML, se puede crear de forma declarativa una interfaz de usuario mediante un DSL más simple como:

Button submit {
  label: "Submit";
}

Y se pase por un compilador o post-procesador que lo transforme en el XML que luego carga GtkBuilder:

<object class="GtkButton" id="submit">
  <property name="label">Submit</property>
</object>

Una de las ventajas de usar GtkBuilder es que al separar la interfaz del código, de repente el lenguaje de programación deja de importar tanto, e incluso se pueden mezclar herramientas. Por esta razón, creo que vale la pena confiar en GtkBuilder. Voy a utilizar Blueprint en la medida que sea posible porque creo que es mucho más simple que escribir los XML.

¿Workbench y Meson?

Hoy en día, parece que son necesarios para poder escribir código de una auténtica aplicación hecha en GTK+. Sin embargo, yo ya pasé página y hace bastante tiempo que desinstalé GNOME de mi ordenador. Ahora soy un try-hard de esos que usan i3.

En fin, probablemente acabe pasando por el aro e instalando GNOME Workbench cuando algo no funcione, o cuando esté a punto de tener un MVP, pero al principio voy a intentar mantenerme usando el mínimo número de herramientas posible. No sé cómo saldrá esto.