Manuel show me some nice samples written by Federico for a better-redrawing, I ported the samples (RulerSlow and RulerFast) to C#. The idea is to improve redrawing in MonoCanvas, I also found two usefull methods Gdk.Window.FreezeUpdates and Gdk.Window.ThawUpdates for avoiding not-needed drawing, in the SWF world their equivalents would be System.Windows.Forms.Control.SuspendLayout and System.Windows.Forms.Control.ResumeLayout.

The updating to the Gtk# based version is closest ever, I’m missing Copy&Paste, DnD and MonoCanvas.Line, no doubt Line’s implementation will take some time due to behavioral details when line is “glued” to other elements, after finishing it first release will hit the streets. While implementing this API I’ve been testing performance against its older brother, and yes, works better and faster, I was worried about this last solution wouldn’t choose any other if this fails! . I feel exaggerating is good to test your application in the worst case scenario, some kind of extremist but doing it that way feels better.

Subclassing Shapes in MonoCanvas is easy, you need to implement the InnerElement, usually the drawn element, and subclass from ShapeGroup. The following is a sample that would be Actor class, spplited in ActorElement.cs:

using System;
using Drawing = System.Drawing;
using MonoCanvas;

}

And ActorShape.cs:

using Gtk;
using Gdk;
using System;
using MonoCanvas;

}

Notice the following, ActorElement class only draws the Actor but might be doing other things, the second parameter of ShapeGroup.AddShape, determines Shape’s independece, meaning that the Shape is allowed to act as an Independent Shape (Moved and Resizing be dragging). This is a quick sample for subclassing MonoCanvas, the idea is to be easy and rapid to implement to create UMLCanvas.

Wondering about MonoCanvas? See it in action:

Notice the colored text thanks to Pango, and the that ‘fine’ drawing thanks to Cairo.

I don’t usually send emails to mailing lists that am subscribed to and wait for an answer, when I do is because I couldn’t find any solution to my problem or, in the other way, want to announce something (like our Mono Hispano ezine!). However I (think that) finally find the answer (’cause still needs further testing) for bringing-to-front widgets drawn in a Gtk.Layout, using the following code as primary sample:

using Gtk;
using System;

public class Sample
{
public static void Main ()
{
Application.Init ();
Window window = new Window ("");
Layout layout = new Layout (new Adjustment (IntPtr.Zero),
new Adjustment (IntPtr.Zero));
Button b1 = new Button ("1");
Button b2 = new Button ("2");
layout.Put (b1, 10, 20);
layout.Put (b2, 15, 15);
ScrolledWindow scrolled = new ScrolledWindow ();
scrolled.AddWithViewport (layout);
window.Add (scrolled);
window.ShowAll ();
Application.Run ();
}
}

You will notice the overlap of b2 over b1, if you switch lines b1 overlaps b2, however, there isn’t a solution for doing this after showing the Gtk.Window.

Solution? Use Gtk.EventBox, after reading gmane’s archive I figured it out! However I didn’t know Gtk.Button doesn’t owns a Gdk.Window, by don’t owning a Gdk.Window, Gtk.Button draws over anything (or any other Gdk.Windowless-widget) so, that might the problem am facing recently. Using Gdk.Window.Lower (), sends to back, Next code shows solution:

using Gtk;
using System;

public static void ButtonClick (object o, EventArgs a)
{
Button b = o as Button;
b.GdkWindow.Raise ();
}
}

Nice!. By the way, Rodolfo and I improved MonoUML a little bit, now MonoUML gots its history navigator

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.

I said, some time ago, that MonoCanvas will be released past month, February, for some reasons, it didn’t, we have implemented a lot of features and some minor ones features are missing, but I still don’t like its performance when drawing many shapes. After thinking for a while I’ve decided to draw-only-those-who-need-drawing, not every shape, this, of course, will improve rendering and redrawing, will consume less resources and will allow a smoother canvas interface.

The idea is simple, but effective, sort when adding shapes, after unpressing mouse button reorder moved-shape/s, this for keeping an ordered shapes-drawn-list. BY doing this will allow us, first to get the shapes that are moved, then calculate who shapes need to be re-drawn and of course by using its position will be faster to know over wich shape we are. I’m still fighting with the improvement of the binary search algorithm, but when finished, everything will be very smoother and better.

Nowadays I been hacking MonoCanvas and recently I’ve been adding some things that reflect a correct canvas-behaviour such as to stop moving when reaching top-most and left-most position, I mean, negative canvas’ positions are not allowed, to stop moving the shape isn’t a real problem but when the shape has inner shapes, that’s the real problem!

I’m scratching my head for allowing this correct behavior…

But when finished will be nicer!

Finally lines are working right. Next step is allow DnD from lines to shapes, in the meanwhile I’ve enabled the antialising support (two simple lines of code), updated configure.in also reflects the changes. Do you notice the difference?

After testing the class I noticed that works with 2 bytes… and should work with greather lengths, but I still don’t like its performance… too many loops… needs further reviewing. BTW, I’ve fixed the one MonoCanvas bug, now the DnD works in a better way, first release is closer!!

Yesterday I went to bed too late… I was compiling mono in QNX, first, there are missing some details for compiling the Boehm GC and then.. I couldn’t finish its compiling due to some -lgthread missing in gcc. Still need “to dive” into the code for fixing these issues.

Using graphics for representing ideas is quite usefull and the “DnD idea” is really good. Dragging and dropping represents the idea of adding, moving or sending information from a source to a target. I’ve been playing with this idea this week and I’m happy with this preview. There are bugs, I found two, Cursor bug, doesn’t change when starting dragging and drag-begin bug that doesn’t call the IDraggable.DragBegin when should be.

I did an implementation based on a mix of Gtk#‘s and System.Windows.Forms‘ DnD methods, comments are allowed and hearing/reading them would be very nice. The idea using two interfaces that represent the Draggable and the Droppable shapes, current implementation is

which means:

I did a sample screencast.