[MonoDevelop] Add-in questions & Assembly questions

[Michael Hutchinson]

On Tue, May 19, 2009 at 1:28 PM, Anirudh <anirudh at anirudhsanjeev.org> wrote:
> Hi.
>
> I think I figured the problem out, but not by changing the package configure
> path, but by forcing the freshly compiled assemblies.
>
> I went to the references edit page for my particular project (which is in
> main/addins) and changed the references to the MonoDevelop.Components.dll
> and MonoDevelop.Ide.dll assemblies, which I had to browse and select. If I
> tried loading the assemblies from the projects, there are only a few
> projects displayed, lib libstetic and NUnitRunner, etc, but not the real
> projects.
>
> At the end of the day, what was supposed to work worked. Moreover, it isn't
> taking too long to compile which is good.
>
> So should I bother with the makefiles now or keep manually adding
> assemblies?
>
> Also, are there any specific advantages towards keeping my stuff in extra/
> rather than in main/Addins/...? I notice a significant slowdown on the
> machine which I'm using when I use the full workspace, rather than an
> individual solution.

When we add your addin to MD SVN, it'll likely have to go in extras,
but until then, if it makes things easier for you, it's fine to keep
it in main/AddIns.

The build system for extras is designed so each addin can distributed
separately and built against an installed copy of MD (though the
top-level configure script can hook them into the main build for
convenience). This is useful for addins that are incomplete or
unstable, or have a different release cycle from main MD, or bring in
large dependencies.

> Any suggestion on where to start for adding a new pad? Also I'll need to
> have a look at some usage of the ExtensibleTreeView class.

The ClassPad in IDE is an example of both. Other than that, there are
pads everywhere -- for example, DesignerSupport's outline pad, or the
debugger pads. IIRC AssemblyBrowser uses ExtensibleTreeView too.

-- 
Michael Hutchinson
http://mjhutchinson.com