I’ve set two bugs to include OCL files into gtksourceview and shared-mime-info, however while this happends I’ll keep working in the editor to include it in MonoUML.
In the Reverse Engineering from sources implementation I’m begginning with the Visual Basic .NET parser. I’m trying to finish it faster as possible.
By the way to those Mono Hispano readers, I’ve also set a bug related to its Wiki.
After removing that sort-like code used within the Reverse Engineering from CIL I’m beginning the API writing to allow Reverse Engineering from sources. Rodolfo, time ago, talked about this idea, I suggested using JavaCC for doing this, he said “Try antlr“, now I’m seeing it, trying to build it to then used it in MonoUML.
However, I still don’t like the idea to include another dependency (ikvm’s dll and so on) in MonoUML, there might be a .NET-based parser generator, but Antlr is quite good and there’s also C# support!, however I haven’t yet compiled C# runtime, why? there are missing files… you just can’t compile it! Not including files in releases drives me crazy, how would I try it and learn it without being able to compile it!?
I’ll spend this weekend trying to solve this.
I’ve been inverting a lot of my time working in the current canvas forgeting the main project, MonoUML, we need to upgrade the project, adding features while working in the canvas, I’m taking over the project again, doing some wiki documentation and begining to improve missing things, fixing bugs and everything else. MonoCanvas will be implementent while updating and improving MonoUML.
Going back to MonoUML!!
My current goals while helping Manuel to finish MonoCanvas are:
At least two hours every day from Monday to Friday and all the day in weekend will do the trick.
Forge Novell have enabled Bugzilla support for hosted projects, now MonoUML has its bugzilla!, see the wiki too 
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 class Sample
{
public static void Main ()
{
Application.Init ();
EventBox e1 = new EventBox ();
EventBox e2 = new EventBox ();
Window window = new Window ("");
Layout layout = new Layout (new Adjustment (IntPtr.Zero),
new Adjustment (IntPtr.Zero));
layout.Add (e1);
layout.Add (e2);
Button b1 = new Button ("1");
b1.Clicked += new EventHandler (ButtonClick);
e1.Add (b1);
Button b2 = new Button ("2");
b2.Clicked += new EventHandler (ButtonClick);
e2.Add (b2);
layout.Move (e1, 10, 20);
layout.Move (e2, 15, 15);
ScrolledWindow scrolled = new ScrolledWindow ();
scrolled.AddWithViewport (layout);
window.Add (scrolled);
window.ShowAll ();
Application.Run ();
}
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
Después de la caida de 3 días del servidor donde estamos hospedados, enzo nos hizo el grandioso favor de ponernos de vuelta al aire, es extraño quedarse sin casa.
La base de datos de mediawiki esta corrupta, mañana con más calma y ganas haré la corrección por mientras hacía forge.novell.
I don’t know why but I feel very happy, too much coffee maybe, however, this night, like every night, I begin reading planetalinux and I notice a very beautifull t-shirt (I hope Jacob don’t get mad at me because I took his photo)
Notice Jacob‘s t-shirt! Powered by MonoUML . Pretty amazing!
The other day I bought a nice book… and thought… wouldn’t it be nice having our own MonoUML CD?
I spent this weekend thinking about some many things, monouml-things. It all began after reading (days ago) alo’s post when I notice that maybe taking his effort and wrapping the libraries would be nice for allowing GroupWare in MonoUML, of course in the near future… we haven’t yet finished MonoCanvas, but the ideas are nice. I talked with Rodolfo, telling this idea for using the WebServices-based communication, yes I know, WS aren’t the best either… He suggested a better solution: CORBA. I agree with him, but using CORBA adds another dependency, so does cherokee-wrapping… Anyway I just need to think more while implementing MonoCanvas.
There are some things that a want to upgrade, some of then are related to usability, such as better DnD within the Views, nicer UIs, better usage space… MonoUML needs love.
MonoUML in japanese? Thanks to Atsushi Eno for his translation.
BTW. MonoCanvas’ performance is better. There are cursors to represent states while moving and resizing shapes. IMO everthing is looking better
Hello! This is me!
