Finalmente, el paso a wx3 y unicode en Zinjai y PSeInt

Hace años que me quejo de mí mismo por estar atado a la versión 2.8.12 en modo ansi de wxWidgets. Siempre decía que el cambio a las versiones 3.x, junto con el paso al modo unicode, requería muuucho trabajo. Necesario, sí, pero demasiado para el poco tiempo que disponía. El problema de macOS y los 64bits me obligó a concretar en parte la tan postergada migración de PSeInt. Quedaron conviviendo ambas versiones, y de a poco la versión 3 fue ganando terreno. Sin embargo, culpa de estos cambios aparecieron errores nuevos, algunos bastante notorios.

Los desafíos de portar PSeInt a macOS Catalina (3/3): Los últimos detalles

Ya conté los problemas y soluciones para poner en marcha un toolchain para las nuevas versiones de macOS, y la migración del código de wx 2 ansi a wx 3 unicode, en GNU/Linux. Solo me faltaba combinar todo esto para ver si andaba en macOS, si tenía un paquete para publicar en el sitio. Por supuesto que no anduvo a la primera. He aquí los últimos detalles de esta historia.

Los desafíos de portar PSeInt a macOS Catalina (2/3): PSeInt vs. wxWidgets

Siguiendo con la serie de problemas y soluciones relacionados a la compilación de PSeInt para macOS Catalina, ahora toca hablar de la relación entre PSeInt y la biblioteca wxWidgets. Resumiendo: PSeInt estaba escrito para una versión muuuy vieja de wx; y además cuando lo empecé había dos formas de compilar wx, y PSeInt usaba la que ya casi no existe. Por esto, aún teniendo un toolchain nuevo que puede compilar una wx nueva, el código de PSeInt requirió de muchísimos cambios y ajustes.

Los desafíos de portar PSeInt a macOS Catalina (1/3): El Toolchain

Finalmente PSeInt anda (eso parece) en macOS de 64bits! Las versiones anteriores eran de 32bits, y la novedad en macOS Catalina es que ya no acepta aplicaciones de 32bits. Las versiones previas de macOS habían empezada a avisar que en cualquier momento esto iba a suceder. Pensé que esperarían más tiempo, pero no, pasó, y PSeInt no estaba listo.

¿Por qué? ¿No es simplemente recompilar todo con otras banderas? Resulta que no, que tenía vaaarios problemas. El primero de ellos era obtener acceso fácil (automatizable con scripts) y permanente (no una mac prestada, algo que tenga siempre en mi propio sistema) a un toolchain adecuado.

Sobre los problemas de PSeInt en Mac OS

Desde hace meses venía recibiendo reportes de usuarios de PSeInt en Mac advirtiendo que una vez iniciado el editor, no se abrían ni la ventana de ejecución, ni el editor de diagramas de flujo (o sea que era completamente inútil). Y era un problema que no podía reproducir yo mismo, así que me era muy difícil de analizar, mucho más de corregir. Finalmente la semana pude hacerlo, encontré una solución que publiqué hace unos pocos días. Pero esto destapó viejos problemas en mi modelo de desarrollo para Mac OS; problemas que ya conocía y sabía que eran un bomba de tiempo.

MinGW64 disponible como complemento para ZinjaI

Finalmente logré hacerme un poco de tiempo para completar la compilación de las bibliotecas de la sección complementos con mingw64, y empaquetar todo, también al mismísimo compilador. Dejó aquí instrucciones para instalar y usar esto, junto con algunas aclaraciones importantes para quienes no tengan del todo claro qué implica el cambio de compilador.

Nota obvia: Este post es solo para quienes utilizan ZinjaI en Windows; ya que en GNU/Linux el compilador no depende de ZinjaI, sino de la distribución de GNU/Linux que se use.

Sobre los nuevos íconos y las pantallas HiDPI

Como habrán notado muchos usuarios, las últimas actualizaciones de ZinjaI y PSeInt presentan sets de íconos renovados. El cambio es simple pero se nota, y hasta he recibido buenas críticas al respecto. Además de buscar actualizar un poco el tema de íconos, este cambio viene de la mano de otro más funcional, que es el soporte para pantallas HiDPI.  Los que tengan notebooks con pantallas 1080p o más deberían haber notado, si usan Windows o Mac, que el texto se ve "mal/feo" (como pixelado, o con un anti-aliasing muy berreta), o, si usan GNU/Linux, que todo se ve muy pequeño. Lo segundo es más fácil de entender/imaginar, pero lo de Windows tiene sus aristas.

Aplicando cambios sin reiniciar en C/C++ (toma 2 -cont.)

Hace poco les conté cómo usar bibliotecas dinámicas para emular una suerte de "edit and continue" en cierto tipo de programas. La idea es simple: la parte que quería poder editar durante la ejecución (conjunto de clases y funciones) va a parar a una biblioteca dinámica. En lugar de dejar que el compilador la enlace al ejecutable, voy por la vía complicada y realizo la carga de la biblioteca "manualmente". Esto me da la posibilidad de descargarla y volverla a cargar en cualquier momento (cuando cambie). El post detallaba cómo hacerlo en GNU/Linux; pero ahora me di cuenta que en Windows hay cuatro problemas nuevos e interesantes para tener en cuenta.

ZinjaI y PSeInt "portables" (para llevar)

Pongo "portables" entre comillas porque me voy a referir a una definición de "portable" que no me gusta. En mis tiempos (como diría el abuelo Simpson) "portable" significaba que podía ejecutarse en diferentes plataformas (GNU/Linux, Windows, Mac OSX, Android, etc). En algún momento el mundo cambió y para cuando yo me di cuenta en Internet se hablaba de "portable" como sinónimo de "no tenés que instalarlo" o "te copias la carpeta en el pendrive y lo corrés desde ahí". Bien, les vengo a contar cómo conseguir esa "portabilidad" [trucha] para ZinjaI y PSeInt. No es mucho trabajo, pero hay un detalle que no estaba documentado y que viene muy bien para el caso. Por si alguno llegó pensando en la otra "portabilidad" (la buena :), de esa ya había hablado en este post.

¿Cómo escribir aplicaciones portables?

Antes de decir nada tengo que hacer una aclaración sobre el título, y es qué entiendo por "portable", ya que es una palabra que se puede usar para indicar varias cosas y su significado por defecto en relación a aplicaciones de software creo que ha cambiado con el tiempo. Cuando yo uso "portable", me refiero a aplicaciones que pueden correr en distintos sistemas operativos o arquitecturas de software y hardware (por ejemplo, que puedo hacer andar tanto en Windows como GNU/Linux). La idea es que una aplicación es más portable cuanto menos depende de elementos específicos de un sistema operativo en particular. Creo que los desarrolladores seguimos teniendo ese concepto asociado a "portabilidad".

Sin embargo, actualmente muchos usuarios finales asocian "portable" al hecho de poder llevar la aplicación de una PC a otra en su pendrive para usar sin necesidad de instalarla, como un solo exe que se ejecuta y ya, o como un zip que solo hay que descomprimir. De hecho pueden encontrar googleando que por ahí alguien ofrece PSeInt portable o ZinjaI portable en este sentido, y supongo que todo lo que hizo ese alguien fue instalarlo en una pc y luego comprimir la carpeta de instalación en un zip/rar/autoextraíble/lo-que-prefieran. No se dejen engañar, mis programas se pueden copiar sin necesidad de instalar, siempre, cualquier versión, sin problemas ni modificaciones. El único trabajo adicional que hace el instalador es crear accesos directos y asociar las extenciones, pero sacando eso, no es más que un gran zip preguntando donde descomprimirse (lugar que tranquilamente puede ser un pendrive). Pero esa no es la idea de portabilidad que me preocupa, sino la anterior, y de los detalles de implementación relacionadas a esa primer interpretación es de lo que habla este post.

Sobre Dibujos y Bibliotecas

El fin de semana pasado me puse a escribir un graficador de de diagramas de Gantt. Mi hermano está trabajando en el modelado de problemas de de planificación y me había comentado que necesitaba algo para visualizar mejor los resultados que le daba el solver. En principio dibujar un diagrama de Gantt no debería requerir de mucha magia, son solo rectangulitos de colores agrupados con algún criterio por fila. Pero otra vez se me apareció la misma pregunta que me hago cada vez que tengo que hacer un programa de esta naturaleza. Por un programa de esta naturaleza entiéndase un programa con gráficos armados a pata (donde dibujo lineas, rectángulos, puntos uno por uno), lo cual implica una API gráfica con funciones de un nivel relativamente bajo, pero donde hay cosas que configurar, que ingresar, que elegir, y entonces donde también quiero tener alguna que otra facilidad de más alto nivel, como la posibilidad de hacer menúes, botones, y demás controles y cuadros de diálogo estándar.

El problema de como dibujar lo enfrenté muchas veces desde que entré en la universidad y lo solucioné de formas muy diferentes. La primera vez necesitaba ver una simulación de una colonia de hormigas para un contest, donde el objetivo era "programar" una hormiga, pero los organizadores no nos facilitaban el simulador. Como la cosa era contra-reloj, no tenía tiempo de aprender algo nuevo, así que fui por el viejo y querido QBasic y sus comandos de dibujo en los modos gráficos de una ventana de DOS. Muy poco elegante, pero sirvió para salir del paso. La segunda vez tenía que simular la planificación de tareas de un sistema operativo para un práctico de la materia Sistemas Operativos, y para verlo usé OpenGL, sin saber mucho y copiando pedazos de código que encontré en Internet. Antes de la tercera vez pasé por la materia Captura y Procesamiento de Imágenes, donde nos enseñaron a utilizar la biblioteca CImg.

Actualizaciones automáticas, instalación de complementos, y Windows haciendo cosas raras

En el sitio de ZinjaI agregé hace un tiempo una sección de complementos y versiones de prueba entre las descargas. Lo que uno encuentra allí son ejecutables de versiones no estables (¿alguna lo es realmente?... no, pero estos no están ni testeados a veces) y archivos para facilitar el trabajo con bibliotecas (templates de proyectos, archivos para el autocompletado, binarios, documentación, etc.). Estos archivos se presentan como comprimidos (zip o tgz) y la "instalación" consiste en que el usuario lo descargue y lo descomprima encima de la instalación original de ZinjaI.

Por el momento sólo hay un complemento (para trabajar con la biblioteca SFML) y encima no muy actualizado, pero me gustaría mejorar esa situación actualizándolo y agregando algunos otros. Dándole vueltas al asunto empecé a analizar la idea de incorporar una opción de menú para instalar los complementos directamente desde ZinjaI. Es decir, que ZinjaI los descomprima donde el sabe de modo que no haya forma de equivocarse, y podría ser que en el futuro, además de descomprimir, también ejecute algunas acciones como alterar configuraciones para colocar botones accesos a las referencias en la barra de herramientas.

De la instalación de complementos desde el mismo programa surgen dos tópicos interesantes para comentar: 1) ¿que tal si hago que ZinjaI acceda al sitio y descargue él los complementos para que el proceso sea todavía más fácil y rápido?, y 2) algunas cuestiones de implementación relacionadas a los privilegios y permisos de usuario que requiere esta instalación.