[MonoDevelop] The new solution pad

[Lluis Sanchez]

On dv, 2005-02-18 at 15:44 +0100, Michael Lausch wrote:
> 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.

The solution pad is just a view of the solution tree, and it doesn't
need to have the same tree structure, which means that a conversion is
always needed. Is that bad? no. The best tree structure for displaying a
solution in the pad is not necessarily the best structure for storing
and managing projects internally.

> 
> > 
> > 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?

The type of the node is the type of the object that the node represents:
Combine, Project, ProjectFile, ProjectReference, etc.

> 
> > 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. 

We'll need to add some kind of priority property to the builder for
this.

> 
> > 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
> > 
> 
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list