En venganza por las dificultades técnicas y la falta de colaboración que condujeron a la interrupción del episodio de «El MicroKernel» del sabado pasado, y con el desafío de superar en calidad de trolling al post de pandev, voy a recurrir al humor del blog Linux Haters para dejar unas cuantas cosas en claro.
Cómo escribir una aplicación KDE.
- Buscá alguna aplicación de código abierto semi-exitosa
- Convéncete de que escribir en C++ es la forma suprema de masturbarse, y que aprender Qt es mejor que pasar el tiempo con tu novia, porque es tan hermoso
- Recuérdate por qué MOC (Music On Console) no es malo.
- Toma el nombre de la aplicación, sed s/[cg]/k/, verifica que no acabes con tres kas en linea. Si no hay kas, añade una al principio.
- Piensa en cualquier función de cara al usuario que pueda proveer tu aplicación
- Foreach function: crear una capa de abstracción que soporte malamente al menos 3 otros backends
- Foreach function: crear botón en la barra de herramientas
- Foreach function: crear item de menú
- Asegúrate que pueda partir ventanas, crear pestañas y soportar KParts. Si no podés pensar en una UI, imita una de Windows.
- Asegúrate que use Phonon, y KAddressBook. Y una Terminal acoplable.
- NUNCA uses una librería cuyo nombre tenga una g. NUNCA.
- Publícala en KDE-Look.org
- Promete a todos que la portarás a Windows, pero no lo hagas
- Una vez cada unos pocos años, usa la revisión del toolkit como excusa para volver a empezar desde cero.
Cómo escribir una aplicación GNOME.
- Busca alguna aplicación razonable de alguna otra plataforma (Windows, Mac, KDE, la que sea, preferentemente Mac). Puntos extra si ya existen 3 otras alternativas basadas en gtk que no se quieren integrar a Gnome.
- El nombre DEBE tener una g. Puntos extra si puede ser una «gn». Si puedes usar «gnu» o «gno» o «gna» eres gegnial, y tu aplicación valdrá la pena usarla. Asegúrate que el nombre de tu aplicación no tenga mucho que ver con lo que en verdad hace. Además, NUNCA documentes si la g se pronuncia fuerte.
- La O en Gnome significa objeto. Utiliza el framework de objetos D-Bus. Si usas también Bonobo, mejor. Asegúrate que al menos una plataforma funcione en la red, pero también asegúrate que tu aplicación nunca la utilize en la red.
- Recuérdate que la Orientaación a Objetos en C no es tan mala. assert(gtk_no_en_serio_no_es_tan_malo). Además, recuérda que GTK+ es mucho mejor que Qt porque no tiene una compañía comercial escribiendo código para este. Así que, ya sabes, es más libre o algo así, y tiene un + en el nombre.
- Genera wrappers para cada lenguaje concebible, pero asegúrate que ninguno funcione exáctamente como quieres. Inisiste que tu distro empaquete cada wrapper en un paquete separado.
- Explícale a al menos tres otros programadores cómo glib no tiene mucho que ver con gnome. Porque les importa.
- ¡No olvides los íconos Tango!
- Asegúrate que tu aplicación compile en windows, pero que se vea como una MIERDA.
- Enumera todas las características que quieres que tu aplicación tenga.
- Descarta el 90% de ellas. Porque son difíciles de hacer. Pero diles a todos que en verdad no las necesitan.
- Implementa el 2% de ellas. Oculta el otro 8% en gconf. Ocúltalas bien.
- Tu interfaz no debe tener más de 4 botones.
- Asegúrate que tu aplicación dependa de al menos otras 4 librerías que tengan una g en el nombre. La vuelve más gnomera.
- No uses Mono, porque contagiarás tu ETS a todos. No, espera, usa Mono, porque te hará mucho más productivo. Espera, no, no uses Mono, porque si lo haces, alguna distro libretardada que nadie usa no distribuirá tu aplicación.
- Que dependa de un módulo que esté «dirigiéndose hacia la obsolencia programada»
- Tranquilízate de que aunque tu aplicación apesta, al menos sigue las guías de interfaz humana.