[MonoDevelop] The new solution pad

[Michael Lausch]

On Mon, 2005-02-14 at 15:17 +0100, Lluis Sanchez wrote:
> Hi!
> 
> I'm working on the new solution pad, and I'd like to explain how I think
> it should work.
> 
> The first design idea is to have a hierarchy of TreeNode classes, so we
> would have ProjectNode, CombineNode, FileNode, AspFileNode and so on.
> 
> There are two reasons why I think this design is not so good.
> 
>       * This model is not extensible enough. It can be vertically
>         extended easily, by adding new subclasses in the hierarchy (e.g.
>         new project or file types), but it's difficult to extend
>         horizontally. For example, an SVN addin would need to show a
>         special icon overlay for ALL files locally modified, and there
>         isn't an easy way to add this functionality to all existing
>         FileNode classes.

>       * With this design, for every node in the tree we have three
>         objects: the internal gtk data structure, the data object that
>         the node represents (e.g. the ProjectFile), and the TreeNode
>         that links both. I think the last one is not necessary and we
>         can save some memory avoiding it.

one possibility to reduce the number of objects is to implement the
TreeModel Interface in the solutionpad.  All you ned is the node and the
internal gtk data structures. And the solution tree *is* the model for
the gtk treeview, eliminating the conversion step from the solution tree
to the gtk treemodel.

> 
> So, my idea is to have a set of Node Builders, instead of a hierarchy of
> nodes. NodeBuilders can handle one specific type of data, or multiple
> types of data, and can be chained to provide composite functionality.
> NodeBuilder would have the following interface:
> 
> public abstract class NodeBuilder
> {
> 	protected ITreeBuilderContext Context { get {...} }
> 
> 	public abstract bool CanBuildNode (Type dataType);
> 
> 	public Gdk.Pixbuf BuildIcon (Gdk.Pixbuf icon, object dataObject) {...}
> 	
> 	public string BuildLabel (string label, object dataObject) {...}
> 	
> 	public void BuildChildNodes (BuildContext ctx, object dataObject) {...}
> 
> 	public DragOperation CanDrag (object dataObject) {...}
> 	
> 	public bool CanDrop (object dataObject, DragOperation operation) {...}
> 	
> 	public void OnDrop (object dataObject, DragOperation operation) {...}
> 	
> 	public virtual void OnSelect (object dataObject) {...}
> 	
> 	public virtual void OnAction (object dataObject) {...}
> 	
> }
> 

the code first has to determine the type of the node to be built. how is
this done? or is the type parameter of the CanBuild() function something
like e.g. System.IO.File for filesystem based objects?

> By implementing the CanBuildNode method, a NodeBuilder specifies the
> kind of data to which it will be applied. The solution pad will create
> and cache a chain of NodeBuilder objects for each data type (not for
> each data object). All builders in a chain will be used to build the

who and how is the order in the chain defined? the NodeBuilder
generating the SVN icon overlay should do it's work after the
NodeBuilder generating the file icon has prepared the pixmap for the
icon. 

> node. For example, to build the tree node label, it will call BuildLabel
> in sequence for all builders, so all of them will have a chance of
> adding text to the label.

[deleted]

> That's all for now. Comments are welcome.
> Lluis.
> 
> 
> 
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list
>