Mar 11, 2006

MonoCanvas, recapitulando.

Estos meses han sido dedicados a la escritura de la API que renderizará los diagramas en MonoUML, hemos avanzado, es cierto, hemos creado una buena API, organizada, pero desde mi punto de vista, muy estricto generalmente, tiene un detalle que a mi forma de ver, no me gusta ni me agrada ni quiero que exista, ese detalle radica en el hecho de la pobre capacidad de manejar múltiples elementos (más de 100 elementos) dibujados al instante, el manejo y el dibujado de ellos. Es cierto que estamos atrasadísimos, claro, nadie nos presiona, salvo nosotros mismos, pues el compromiso es con nosotros, pero si algo he aprendido es que lo mejor es tener una API estable, que funcione eficientemente y que sea escalable, a liberar porquerías inservibles, a pesar de escribir un buen algoritmo para que la selección de elementos y movimiento de ellos haya sido definido el desempeño sigue siendo pobre (o bueno.. no tan bueno como yo pensé) y la calidad de nuestro esfuerzo debe sobresalir, si estamos escribiendo una aplicación que ayudará a documentar, ((además de otras cosas cosas) cosa que es, en ocasiones, pesada, molesta y aburrida y además creemos (de forma totalmente erronea) que quita tiempo), debemos de crear algo que realmente sea bueno.

He pensado diferentes soluciones, sin duda la mejor (o si alguien tiene otra mejor que opine) es crear hacer subclasses de Gtk.Widget (o Gtk.DrawingArea) y a partir de ahí escribir nuestros elementos, esta no es una decisión final, pero sin encambio haré pruebas para probar su desempeño en comparación a la versión actual, estos cambios me desesperan, es cierto que siempre llega un instante en el que no se puede mejorar más tu software a menos que cambies el hardware, pero quiero que ese límite no este definido por la capacidad de mi equipo actual, sino por la capacidad de un equipo considerablemente menor.

Sin duda escribir Widgets que deriven de Gtk.DrawingArea hará que cosas como: saber sobré que Widget estoy o saber si le di click a un Widget sea más rápido, eficiente y transparente, pues los eventos no son procesados y luego generados por la misma API sino por el sistema de ventanas. Es claro que hacer esto atrasará la salida de la primera versión un tiempo, pero mi misión es terminarlo lo más pronto posible, me gustaría ver este año una segunda versión de MonoUML, hemos hecho varias cosas y sería grato mostrar nuestro avance, ahora que Gtk# 2.8 es la versión propuesta como estable, sería grandioso liberar pronto una versión de MonoUML para que forme parte de las distribuciones. Todo el equipo ha estado tan ocupado, pero seguimos trabajando, lento pero seguro.

Simples pensamientos. Aún hay cosas que hacer.

Por otro lado, pronto inicio un buen proyecto con Linux en mi trabajo, no será 100% en él, pero sin duda disfrutaré trabajando este año próximo, pues esta pensado para un año de duro esfuerzo, se avecinan buenas cosas.