[MonoDevelop] Thoughts about AddIns

[John Luke]

On Thu, 2004-04-08 at 13:55 +0200, Mike Krueger wrote:
> Hi
> 
> >The problem that I see arising is enabling/disabling various addins with
> >various dependencies (which may not even be written in C#) and
> >installing them easily.  Most plugin-enabled apps I have used have a UI
> >for managing these things, which could include the possibility of adding
> >an addin automatically via a url.  Also, I think shipping most of the
> >possible addins with monodevelop may become a burden and even be
> >undesirable for people with simple needs.
> >
> >  
> >
> This might be ... but for SharpDevelop we have so few developers that it 
> currently doesn't make sense.
> We can integrate all addins and 'hide' them in the right place. From 
> time to time we need to change the
> menu structure a bit (like the view menu lately). But for now all is 
> consistent and looks 'thin' ... what is
> needed for #D is the ability to have different 'views' (gui layouts) for 
> different 'modes' (for example
> debugging).
> But for some add-ins that might pop up it is surely better to download 
> and install them additional. But
> the main goal for #D was to integrate ALL avaiable tools. (Thats why 
> these things are called Integrated
> Development Environment and not VI).

I think it is reasonable to include most addins that you have.  I'm just
talking about the long run if someone writes a addin for a weird
language, a proprietary addin, or with odd unmanaged dependencies I
don't want to include it with the source or packages. I like the
integrate all possible addins approach.  I just want to disable ones I
don't want and give 3rd party's the ability to distribute their own.
Sounds like you have most of this in your AddinScout which I should take
a look at.

I think Todd added a 'context' to display certain menus conditionally
(like when debugging) and when Gtk# moves to GTK 2.4 the action api will
make things like this relatively trivial, at least for menus and
toolbars.

> 
> >I think the solution will be to offer a mechanism similar to the
> >following.  Enable/Disable existing addins without requiring removal of
> >the dll/addin files.  Functionality to download a zip of an independent
> >addin and have it automatically installed to the right place (it may
> >require a xml file that self-describes the functionality and
> >dependencies of the addin).  Installing an addin manually or via a rpm
> >should also still work.
> >
> >  
> >
> This is something that would be really good ... a other good feature 
> would be 'auto-update' of addins.
> (which basically is equal to auto update the IDE).
> But currently #D doesn't go in that direction ... maybe after 1.0.
> 
Yep, update is a good idea.