Re: The state of MonoDevelop

Comments inline :)

On Wed, 2004-01-28 at 08:13, Jeroen Zwartepoorte wrote:
> Hi Todd, 
> 
> On Tue, 2004-01-27 at 22:42, Todd Berman wrote:
[snip]
> Very cool. Why did you decide to try GtkSourceView instead of the port
> of MD's own editor? If you (or Ben) wants to discuss how to
> improve/change gtksourceview, it's best to include Paolo (gedit
> maintainer) and Gustavo (co-maintainer of gtksourceview) in the
> discussion (and please CC me as well :) ).

Ironically, I believe he just did that ;)

We are going with GtkSourceView because of all the things it gives us,
and how nicely it ties into the Gnome Desktop. Ben has a blog entry that
explains in better detail.
http://codeblogs.ximian.com/blogs/benm/archives/000131.html

> > 	I am curious if anyone here has given any thought to using parts or all
> > of what we have for Scaffold or other devtools projects. I feel that
> > there is great potential, as one of C#s greatest abilities is how easy
> > it can work with C, and any other .NET language (For example, there is
> > some good work being done on a python.NET compiler that would allow
> > python to be used.)
> 
> I really like C#. I started a Scaffold port written in C#, but stopped
> developing it after seeing the progress on MD.
> 
> One of the main concerns voiced on this list is that with a C# core,
> it's difficult to have plugins written in different languages (C,
> Python, C++ etc). Have you given thought to this?

Yeah, its something I have been thinking about a bit.

MD (by being a port of #D) already has a very very mature plugin
framework. I was looking at it briefly, and It looks completely feasible
to write a C/C# plugin bridge that would allow you to write plugins in C
and with a small amount of C#, tie them into MD. As for something like
python, as I mentioned, if you take python, and use a compiler like
Python.NET to compile it to the CLI framework, it would interop without
any additional steps.

I believe personally, that getting something like MD to understand and
use C plugins would be far less code/time than getting a C application
to the point MD is at currently. But thats just a personal opinion ;)

> Probably the most interesting piece of code in scaffold is gnome-build:
> there's quite a bit of code that parses configure.in and Makefile.am's
> and builds an XML representation of the automake/conf project. Then
> there's code which allows you to add/remove files without regenerating
> any of the files: doing a diff of the changes would only show the line
> where you would have made the changes yourself.
> 
> Has anybody written any architecture docs btw? It would be nice to get
> an overview of MD's architecture. We're having some discussions on this
> list on how to proceed with scaffold, including some architectural
> changes (expose the inner workings/plugins via some sort of XPath:
> /Documents/Untitled0, /Session etc). See 
> http://webs.uolsinectis.com.ar/gustavog1/scaffold/ for more info)

MD at this point has what is termed an 'AddInTree' that functions
similarly to this setup. At runtime, .addin files (xml) are loaded into
a tree. This allows plugins to effect any piece of the tree they need
to. For example, there are a set of Commands run at startup, and the
StartPage addin adds a command to that list.

The entire menuing system is based off this AddIn system, so it is easy
for plugins to enhance or effect the menuing system.

There is a bit of an architecture essay you can find here:
http://www.icsharpcode.net/TechNotes/ProgramArchitecture.pdf

> What do other people on this list think about scaffold vs MonoDevelop?
> 
> > 	As an aside, please, try and restrict the anti-mono/C# flames a bit ;).
> 
> No worries from me :)
> 
> Cheers,
> 
> Jeroen
> 
> _______________________________________________
> gnome-devtools mailing list
> [email protected]
> http://mail.gnome.org/mailman/listinfo/gnome-devtools