rss resume / curriculum vitae linkedin linkedin gitlab github twitter mastodon instagram
MonoCanvas, recapitulando.
Mar 11, 2006

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.


Back to posts