[Monodevelop-devel] Working on the monodevelop dom after 2.2

[Lluis Sanchez Gual]

El dt 29 de 09 de 2009 a les 00:09 +0200, en/na Mike Krüger va escriure:
> Hi
> 
> > Why is it specific to .NET? I'm missing something here. The document
> > outline shows a hierarchy of items. It is so generic that it even works
> > for XML documents. The class pad is also just a hierarchy of items (for
> > the whole project in this case). The goto type dialog shows a list of
> > types in the solution. 
> > 
> > The quick member navigation shows types in the first combo, and members
> > of the types in the second one. It can easily be redefined to showing
> > 'first level items of the file' in the first combo, and 'children of the
> > active first level item' in the second combo. Or something like that.
> > 
> > I don't see anything .NET specific in all this.
> > 
> 
> Ok I've looked a bit at the source code.
> 
> Class pad:
> 
> ClassNodeBuilder, FieldNodeBuilder, MethodNodeBuilder,
> NamespaceNodeBuilder etc. 
> 
> But it can be extended using the addin tree - but the things we have are
> very specific. For example: I've took a look at the MethodNodeBuilder -
> it doesn't build child nodes (yes there are languages with methods in
> methods). Taking this example it wouldn't even work if we had a new
> INewMethod interface for such a language to be build with the class pad,
> because the MethodNodeBuilder that takes care of building these objects
> would prevent building child nodes.

I feel there is some misunderstanding here. If we introduce a new set of
INew* interfaces we'll certainly have to track the changes in
MethodNodeBuilder and all the builders. And those changes will include
rendering child nodes, since any node can have child nodes.

> 
> Quick Member navigation - it's not so easy to set the rules:
> 
> 'showing first level items of the file' means:
> + Showing only the namespaces -> no containing types (they're first
> level, and will be part of the DOM as nodes)
> + Don't show inner types (they're second level at best)
> 
> 'children of the active first level item' means:
> + Show the current inner type (should be in the type selector).
> + Show the current statement, if the DOM is extended and more specific
> than the monodevelop DOM.

This has a very simple solution:

interface IQuickMemberNavigationProvider
{
	IEnumerable<INode> GetTypes ();
	IEnumerable<INode> GetMembers (INode type);
}

to be implemented by language bindings.

> 
> Then there are 3 navigators: types/members/regions. That doesn't make
> sense for some cases (think of C, there are no members/regions). 
> 
> Document outline:
> The document outline that shows the hierarchy requires that
> IOutlinedDocument is implemented. A XML and MD DOM get different
> implementations of this interface. It's very general:
> 
> public interface IOutlinedDocument
> {
> 	Gtk.Widget GetOutlineWidget ();
> 	void ReleaseOutlineWidget ();
> }
> 
> I would say that's one of the best components we have for extensibility.
> Because it doesn't 'lock' into a specific model. The downside is that it
> doesn't provide much to re-use. But I think we should have this sort of
> extensibility for all components and let the non-.NET languages a way to
> work around all pre defined structures and replace the components with
> an own way. This ensures that we can't make a mistake.

But that's not always possible. For example, a solution may contain C#
and C++ projects, and the class pad has to show all of them in a single
tree.

It might work in other cases, for example in the quick member navigation
toolbar.

> 
> btw. another thing: All pads/output function currently build on ambience
> flags - but for other languages there may be different sets of flags
> required for displaying the information at that point. 
> 
> > Yes, that's currently possible (with some tweaks). But it means that the
> > language has to implement all the DOM interfaces: IField, IMethod,
> > IType, etc, which are full of .NET specific stuff. Yes, you can just
> > throw NotSupportedException of all .NET specific methods and properties,
> > but that's just unnecessary bloat. If anything, it would be better to
> > have:
> 
> We've classes that implement the interfaces, no .NET specific
> implementation is required. But the other thing is that a new languages
> now would ALWAYS require to implement all DOM interfaces that are full
> of .NET specific stuff. (ok could use the same base class)
> You've still not told how to display a VB output, Boo output and c#
> output of a reflection source when putting the output code inside the
> DOM objects. I think that's not easily possible.

I showed it some posts ago:

class DomField: IMember, INewField
{
        public string GetDescription (SomeContext ctx)
        {
                return ctx.Ambience.GetString (this, ctx.AmbienceOptions);
        }
        ...
}

> 
> MD side:
> Code Completion DB -> Data (in which DOM format)
> 
> Language binding:
> Own Dom info + wants to display code completion data from the code
> completion db 
> 
> > That would work, although I don't see the benefit of separating data
> > from display data in non .NET languages, since there will be a 1 to 1
> > correspondence between data and display data.
> >
> 
> The benefit is that the non .NET languages can communicate with
> MonoDevelop components to produce output. And that the .NET unspecific
> types/members etc. could be implemented today.
> Sometimes the output is altered (adding markup to names etc.) by
> consuming code. Outputting the text from the DOM isn't very easy and
> just a GetString () doesn't cut the edge. We've to display this
> information in various tooltips/lists with different options (short name
> vs. long name). Therefore the GetString () needs to get the same
> parameters as ambiences.

I think we have to look at this case by case. For the tooltip case,
maybe this is enough:

interface ITooltipProvider
{
	string GetMarkup (INode node);
}

to be implemented in every non-.net language binding.

> 
> I tend to make the monodevelop DOM stuff .NET dependent in the type
> model, generalize the object model so that other .NET languages can be
> supported that are more far from C#/VB.NET and have a way to do
> something like the IOutlinedDocument for each component. I don't want to
> make the life harder for .NET language implementors when the non .NET
> language implementors get little to no gain (See above - they need to
> implement their own widgets/infrastructure - regardless of what we try,
> more worse they can run into dead ends when trying to re-use the
> monodevelop DOM - see the class output pad method example).

No, what I'm proposing does not involve implementing additional
widgets/infrastructure. See above.

Lluis.