[MonoDevelop] Update "Addin Development Basics" with new install path

[Michael Hutchinson]

On 5 April 2012 01:22, Joshua Granick <bulkmail at joshuagranick.com> wrote:
> Adding a symlink to that install directory has worked out well. I can close
> MonoDevelop, relaunch and have an up-to-date plugin.
>
> It's been pretty difficult to find what I need so far, but aggregating the
> information I find online, as well as searching all the files in the
> MonoDevelop git repo, have helped me piece together how some of these things
> work.
>
> I'm much farther along than when I dabbled in creating an addin with
> MonoDevelop 2.6 (I think?)... I've already got the custom languages set up,
> with highlighting, as well as my own project types and templates. I couldn't
> figure out how to embed resources into a project template, and it was

You can use the RawFile code in your xpt/xft template:
<RawFile src="someFileRelativeToAddin.png" name="SomeName.png" />

src is relative to the addin location, which means the file will need
to be "copy to output", and don't forget to add a <Runtime><Import
file="... etc. so that the addin depends on this file.

Note you can use the src attribute on a File element too, so the
xft/xpt can become just a manifest. You can even avoid embedding the
manifest itself when you register it: <FileTemplate id = "Foo" file =
"templates/Foo.xft.xml"/>

Although historically, MD addins have kept everything inside the
xft/xpt and embedded it into the template, I would recommend using
files, with the addin structured something like this:
Foo/Foo.dll
Foo/Templates
Foo/Templates/Project.xpt.xml
Foo/Templates/Project/SomePng.png
Foo/Templates/Project/SomeFile.foo

> difficult to find all of the variables you could use in templates (like
> ${Name} and ${ProjectName}), but the big things I need to solve now are
> getting my compilation to work, then investigating code completion.
>
> It will be interesting to figure out, because code completion for my target
> language is provided by the compiler, so I don't have to write a lot of
> parsers to understand the language, but I wonder how that may mess with some

In general, MD provides a lot "for free" for .NET languages or other
languages that interact with the MD type system. It might be possible
for you to map type types into the MD type model to make them
automatically show up in the document outline, tooltips, class view,
etc. Or you might just have to reimplement some of these things, or
alter MD core to make them more extensible.

I can't speculate much on integrating the compiler for code completion
without details, but I'd expect you'll need direct access to AST for
things like folding, document outline, go-to-type, class browser, etc.
You could take a look at the F# addin, since it used the F# compiler
for completion, and I expect it has/had problems similar to those
you'll have.

> of the conveniences MonoDevelop provides. For example, the ${Namespace} tag
> only returns "Application", I assume because I don't have any parsers set up
> to know how the file names and directories relate to the namespace.

All of the substitutable values in the file/project templating system
come from the template handler classes, while provide a lot more
default functionality for .NET projects:
https://github.com/mono/monodevelop/blob/master/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Templates/SingleFileDescriptionTemplate.cs#L337

However, you can register your own template types that add additional
substitutions or even generate the content completely differently:
https://github.com/mono/monodevelop/blob/master/main/src/addins/AspNet/MonoDevelop.AspNet/MonoDevelop.AspNet.addin.xml#L95
https://github.com/mono/monodevelop/blob/master/main/src/addins/AspNet/MonoDevelop.AspNet/MonoDevelop.AspNet/AspNetFileDescriptionTemplate.cs

And then use these in your templates:
https://github.com/mono/monodevelop/blob/master/main/src/addins/AspNet/MonoDevelop.AspNet/Templates/WebForm-CodeBehind.xft.xml#L22

> It would be great to be able to set up the project panel so that it
> automatically adds any files in the target directory as a part of the
> project. It isn't the biggest deal in the world, but its a nuisance coming

Do you want them actually added to the project file, or does the
project implicitly contain all the files in its base folder?

We never did the latter, but it would be useful to have a mechanism
for it, because it's not uncommon - even "ASP.NET web sites" projects
do it. We only support "ASP.NET web apps", which have actual project
files, but I have thought about the problem a bit.

IMO the best way would be a custom project (de)serializer, which would
simply scan the disk and add all the files to the project in memory
when loading the project files, and omit them when writing it back
out.

> over from other editors. I suppose I might be able to constantly poll as a
> part of my project somehow, or maybe this is a behavior that can be altered
> in the existing control?

Polling the filesystem is quite expensive, and FileSystemWatcher
doesn't work reliably on MacOS. Instead, we have a mechanism in the
workspace that detects changes in projects' files by getting mtimes
when MD loses focus, and checking them again when it regains focus.
Maybe you could extend it to also detect added/removed files in
project folders?

> By and large I've been enjoying 2.8 even more than my previous experiences.
> Excited to continue exploring support

Glad it's working out! I know the idea of bringing parts of FD into a
MD addin been discussed on and off for a few years, and it's exciting
to see someone making real progress :)

-- 
Michael Hutchinson
http://mjhutchinson.com