Having fun with properties

If you open the View menu in MonoDevelop you'll find listed there two pads which look very similar: "Properties" and "Widget Properties", and you'll also find "Toolbox" and "Widget Palette". The reason for this duplication is that there are two designer models in the IDE: the Stetic model used by the GTK# designer, and the System.Component based model used by the ASP.NET add-in. Today I decided put an end to this duplication, and I started integrating those pads into a single Properties/Toolbox pair.

The System.Component based toolbox is actually not so System.Component dependent. There is a MonoDevelop.DesignerSupport add-in which implements the property and toolbox pads, and which is designed to be pluggable, so I only had extend it from the GTK# designer. After some fixes and improvements I've been able to show the GTK widgets in the toolbox, and to drag&drop them in the designer. It's almost 100% functional now, there are only some small issues to fix, such as the order in which components are shown. But not too much...

Integrating the properties pads has been a bit more tricky. I wanted the properties pad to be very generic and usable not only for visual designers, but also for the IDE in general. So for example if you select a file in the solution pad you would see the properties of the file.

The first problem about the integration is that the Stetic model and the System.Component model are very different. In particular, properties of Stetic components are defined in class descriptors (specified in an xml file), while System.Component model is purely reflection based. Since it's not trivial to implement a property grid which can support both models, the solution has been to completely replace the properties grid depending on what has the focus. When the focus is in the GTK# designer, the properties pad will show the Stetic property grid, and when clicking on the solution pad, it will show the standard System.Component model property grid. We still have two property viewers, but now we have only one properties pad.

The second problem to be solved, is how to detect that the currently selected object has changed, and that the properties pad has to be updated to show the properties of the new selection. In Stetic it is done by tracking focus change events, but it won't work as a generic solution, because the "currently selected object" can be *anything*, not only widgets. For example, the properties pad should change when the selection in the solution tree changes. So I decided to go for a pull model like the one used by the command manager for updating command status. Status of commands is checked periodically by getting the widget that has the focus. If that widget has a handler for the command, it is executed. If not, the command manager looks for a handler in a route of objects which starts on the active widget. This route is by default the chain parents of the widget, but it can be altered. For example, the solution pad re-routes commands to tree extensions before re-routing back to the parent. In this way node extensions have a chance to provide custom behavior for commands.

How is all this related to the properties pad? Well, I'm using the same command target infrastructure to find a potential target object for the properties pad. So, any class in the command route can now not only handle commands, but also provide the "selected object" to be shown in the pad (it only needs to implement the IPropertyPadProvider interface and specifically the GetSelectedComponent() method). I quickly managed to implement a solution pad extension which implements that interface and returns the current tree selection. The result is what you can see in this screenshot:



That is, by selecting any item in the tree, it will show its properties in the properties pad. It still needs a lot of polishing since some properties need to be hidden (it can be done by applying System.ComponentModel attributes), and the properties grid itself is not very stable, but it's looking nice.