Lluis' Blog  -

+ 4 - 2 | § ¶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.

+ 7 - 1 | § ¶A new GUI designer in MonoDevelop

I just committed the integration of the Stetic GUI designer in MonoDevelop. Yes, Stetic, not Glade-3. If you are wondering the reason for this change, just read the mail I sent to the MD mailing list some time ago.

So, what's new about this new add-in? Well, a lot.

The first thing to take into account is that this is not just a Stetic add-in that provides an integrated designer. The designer is just part of a set of extensions intended to make easier the development of Gtk# applications.

The add-in adds some new commands to the "Add" menu of a project: "Add New Dialog", "Add New Window" and "Add New Widget". The first two commands will create a new Gtk.Dialog or Gtk.Window subclass, which can be visually designed using the designer. You don't have to bother about Stetic files and resources. Everything needed to support the designer will be generated and handled behind the scenes by the add-in.

The "Add New Widget" command is something new. It allows you to create a new widget and use the designer to create its contents. Once the project is compiled, that widget will be shown in the widget palette, and you can use it like any other native widget to design windows or other widgets. Properties defined in the widget's class will be shown in the properties pad, and public events will be available in the signals tab.
That widget will be available to the project that implements it, and to any other project that references it.

Not only widgets created with the "Add New Widget" command can be used in the designer. Any Gtk.Widget subclass implemented in the project can be made available to the designer. There is a new panel in the project options, named Widget Export, which allows you to select which widgets you want to publish.

These features opens a world of possibilites. On one hand, it allows you to split complex user interfaces in several less complex components that can be individually designed. On the other hand, it allows you to create common widget libraries ready to be used by a visual designer.

There are, however, some limitations. For stability and consistency reasons MonoDevelop can't load the widget library DLLs into the main MD process. So, when you add a widget implemented in a widget library to a window, what you see in the designer is not the real widget instance, but a fake widget that looks like it. The widget properties pad will show all widget's properties, but changing them won't have any effect to the widget, since it won't be actually running (although those property values will be stored and loaded at run-time). The ideal solution for this would be to load the widget library assemblies in a separate application domain. Since domains run in the same process, it should be theoretically possible to create a widget in a secondary domain, send the handle to the main domain and use it from there. This is "in theory" because gtk# is right now not ready for this, and I'm not sure it can be adapted to support multiple domains. I any case I plan to do some research, since it would be really cool to be able to dynamically load and unload widget assemblies.

Anyway, what we support now should be enough for most of uses. Here is the mandatory screenshot:

The screenshot shows a solution with two projects. One of them is a widget library that implements a widget named "TestWidget". The other project is an application that references the library. The TestWidget is shown in the palette. The window shown in the designer contains three instances of TestWidget. One of them is selected. The properties pad at the bottom shows a custom property of that widget.

The new add-in is now in SVN. Please try it and report bugs. Beware, it's still beta and some features are still missing (for example, a menu designer). Notice that you don't need to install Stetic, since the necessary libraries are included in the add-in (that's also a big plus over glade-3!!).

Enjoy!