Lluis' Blog

Blog moved

Due to some problems with comment spammers and lack of time to fix it I decided to move my blog to Blogger. The new home for my blog is: http://foodformonkeys.blogspot.com.
Thanks for listening!

Shooting memory

Heap-shot is a new memory profiler I've been working on. I used this profiler in the last MonoDevelop release to track down memory leaks, and it turned out to be really useful. So the idea is the following: you start a mono application using the heap-shot profiler like this:

> mono --profile=heap-shot myapp.exe

Then you start the heap-shot tool by just running:

> heap-shot-gui

When the application is running, click on "Memory snapshot" and select the process you just started. At this point, heap-shot will make a snapshot of the process memory and will load it into the heap-shot tool. You'll see then two tabs: one shows a summary of the snapshot (number of objects and total managed memory), the other tab shows a list of types, and for each type the number of instances, the total memory size and the average size. The list of types is in fact a tree of references. By expanding a type you'll get a list of types referenced by that type. If you want to examine a type in detail, you can double-click on the type name and it will show the type subtree in a separate tab.

It is also possible to see inverse references, that is, see what objects reference objects of a given type. For example, if your app has 2000 int arrays in memory and you want to see what is holding all those int[], just click on the "Inverse references" checkbox and expand the int[] node. You can keep expanding as many levels as you want, what you'll see is something like this:

heap-shot can also show differences between two snapshots (that is, which objects have been allocated between two snapshots). To use this feature just take two snapshots, click on the checkbox of the snapshot you want to use as base snapshot, and then select the second snapshot. All information you'll now see in the references tabs will be about newly allocated objects only.

You can get heap-shot from SVN (module name: heap-shot). The README file has some more information. Enjoy!

Away

I hope I can find time in the following weeks to blog about those wonderful days I spent in Puerto Vallarta (Mexico). I was invited to talk about Mono and MonoDevelop in the 5� Festival GNU/Linux y Software Libre. Right now I'm getting ready for two weeks of holidays, which I'll spend visiting Mexico DF and Chiapas. And after that, I'll be traveling to Boston, where I'll attend the Mono Users and Developers Meeting. I look forward to meet with all Mono friends there!

Visiting Mexico

I'm planning a trip the Mexico next september. I'm going to attend two conferences, the first one is the GULEV in Veracruz, from 14 to 16 september, and the second one is the FSL at Puerto Vallarta, from 27 to 29 september. So in the middle I'll have a couple of weeks of holidays I plan to spend visiting the country.

So, I'm going to do a call for proposals. Taking into account that I have a couple of weeks, and that I want to avoid beach tourism, what are the best places to go? suggestions are welcome!
And of course if somebody wants to meet to talk about Mono or just to have some beers together, just drop me an email (lluis at ximian.com)

An exciting GUADEC

Only a few days left for the GUADEC, wow! I can't wait!. This is going to be my first GUADEC ever, and it will be a very special one since I'll giving three talks in the whole week.

The first one will be next saturday in catalan, as part of the mini-GUADEC we've been organizing for the catalan comunity. GUADEC-CA is going to be a set of sessions with the special goal of introducing GNOME to people who don't know much about the Linux desktop. We've done some advertising of the event among local companies. My talk is done in colaboration with Ramon Navarro. I'll present an overview of the GNOME development platform, and Ramon will be demonstrating how to develop applications using Mono.

On Sunday 25th there will be a small Mono track for the spanish comunity. We have introductory sessions for Mono and GTK#, and I'm giving a talk about MonoDevelop. If you like/use/want to know more about Mono come to see us.

On Wednesday 28th I'll give my official GUADEC talk: "MonoDevelop: a GNOME IDE". You can't miss it if you want to see the latest features of MonoDevelop!

Designing menus

I've been working lately on a menu designer for Stetic/Monodevelop. The designer is based on the UIManager/Action/ActionGroup model, and it has been a real challenge to make easy building menus, and at the same time take advantage of all features this model provides.

Building a menu is really easy and 'visual'. You only need to add a menu bar to the window and start writing options. The menu designer looks like a regular menu, but clicking on a menu it will select it, so you can change its properties using the Properties pad. Clicking again on the menu item when it is selected will start the editing mode of the menu item, in which you can change the label or the icon. This is how it looks like:

When you are creating menu items in this way, at the same time the designer creates Actions for each menu item. Those actions are added to the window's default ActionGroup. In the screenshot you'll see that the widget palette now has a new section named "Actions", which shows all actions added to the window. If you had a toolbar, you could drag & drop those actions into it (not yet implemented, though).

You've also probably noticed a new "Actions" tab in the text editor. This new tab shows a visual representation of the action group bound to the window, and looks like this:

It is basically a list of all actions defined in the window. In this designer you can select and change the properties of the actions, and even bind actions to fields, so you can change the sensitivity or visibility of the action at run time.

This default action group is local to the window, which means that handlers for action signals will be added to the window's class, and fields for the actions will be added also to the window class. It also means that if you create another window with another menu bar, you won't be able to reuse the actions from another window. In case you want to share actions between windows, you'll need to create a global action group. In the New File dialog there is a new icon for creating global action groups. A global action group is not bound to a specific window, but it has its own class, and signals and fields are mapped there. Actions belonging to global action groups will always be shown in the palette, so you can add them to any window.

Icon Factories

Stetic/MonoDevelop can now manage icons to be included in a project. The idea is that you select some images, give them an ID, and Stetic will generate a Gtk.IconFactory for you and will register the icons there. You can then use that ID when creating buttons or whatever that requires an stock id. This was needed to make it easy to create actions with custom images, since actions can only use stock ids, not pixbufs. Here is a screenshot of the Edit Icon dialog:

.NET 2.0 in MonoDevelop

MonoDevelop is now being compiled with gmcs. This change is needed to be able to reuse some of the code from SharpDevelop 2.0, and will allow us to use nice 2.0 features. I also committed NRefactory into MD's svn and made the necessary changes to our c# binding, so now MD can properly parse C# 2.0 source code files. Generic classes are still not very well supported by our c# binding, but at least they are properly parsed. If you find any issue after this change, please let me know. We need to do a good testing before the next release, since this is an important change.

Summer is approaching

I'm really happy with the last MonoDevelop release. Looks like a GUI designer is just what people was waiting for, and we've got very positive feedback. I'm planing a new release (0.11) very soon which will fix many of the bugs reported in the last weeks. MD 0.11 will also have support for compiling .NET 2.0 assemblies. To make it possible I had to change some of the compilation and code completion classes, since they could only manage .NET 1.1 assemblies, or being more precise, assemblies compiled with the same version MD is compiled. Now MD is completely independent from the assemblies it manages (thanks to Cecil!), so we can safely start compiling MD with gmcs, and still be able to support both 1.1 and 2.0 projects. MD 0.12 is probably a good target for this change.

However, we still don't have a parser for C# 2.0, so code completion will not work when using 2.0 syntax. The plan is to reuse the parser from SharpDevelop, and this is yet another reason for compiling MD with gmcs, since SharpDevelop needs .NET 2.0.

I'm also working on the menu designer, but it won't make it for this release. This designer is starting to look really nice, but there are still some issues I need to solve, specially about how to map Actions, Action Groups and their signals into C# classes and methods. In any case, I think the menu designer should be ready for MD 0.12.

I've been able to find some time lately for writing documentation. I updated the Writing an Add-in article (the old one was really obsolete), and added Add-in Extension Tree Reference. This last article is (more or less) automatically generated from the add-in xml files, and provides the complete list of items you can extend in MonoDevelop.

Google Summer Of Code

We have several project proposals for the Google SOC. If you are willing to apply, do it quickly since the deadline is May 8, only 4 days left!

Using TreeView custom editors in GTK#

Right now GTK# has no support for GInterface, which means that you can't implement GTK interfaces such as CellEditable. Due to this limitation, although you can create custom cell renderers (by just subclassing CellRenderer), those cell renderers won't be able to provide custom cell editors. Until we have proper suppor for GInterface, here is a hack to workaround this problem:

// In your CellRenderer...

public override CellEditable StartEditing (Gdk.Event ev, Widget widget, string path, 
	Gdk.Rectangle background_area, Gdk.Rectangle cell_area, CellRendererState flags)
{
	MyEditor editor = new MyEditor ();
	return new TreeViewCellContainer (editor);
}

MyEditor is the widget you want to use as cell editor. It can be any widget, there is no need to implement CellEditable. TreeViewCellContainer is the following class:

class TreeViewCellContainer: Entry
{
	EventBox box;
	
	public TreeViewCellContainer (Gtk.Widget child)
	{
		box = new EventBox ();
		box.ButtonPressEvent += new ButtonPressEventHandler (OnClickBox);
		box.ModifyBg (StateType.Normal, Style.White);
		box.Add (child);
		child.Show ();
		Show ();
	}
	
	[GLib.ConnectBefore]
	void OnClickBox (object s, ButtonPressEventArgs args)
	{
		// Avoid forwarding the button press event to the
		// tree, since it would hide the cell editor.
		args.RetVal = true;
	}
	
	protected override void OnParentSet (Gtk.Widget parent)
	{
		base.OnParentSet (parent);
		
		if (Parent != null) {
			if (ParentWindow != null)
				box.ParentWindow = ParentWindow;
			box.Parent = Parent;
			box.Show ();
		}
		else
			box.Unparent ();
	}
	
	protected override void OnShown ()
	{
		// Do nothing.
	}
	
	protected override void OnSizeAllocated (Gdk.Rectangle allocation)
	{
		base.OnSizeAllocated (allocation);
		box.SizeRequest ();
		box.Allocation = allocation;
	}
}

Enjoy.