[MonoDevelop] Thoughts about AddIns

Todd Berman tberman@sevenl.net
Thu, 08 Apr 2004 13:55:35 -0400


On Thu, 2004-08-04 at 13:45 -0400, John Luke wrote:
> On Thu, 2004-04-08 at 13:55 +0200, Mike Krueger wrote:
> 
> 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.
> 

That I infact just did.

> > 
> > >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.
> 

Well, with this we step into an interesting gray area.

Autoupdate would have to put the files somewhere. and since most
installs will be rpm, and installed into /usr/lib/monodevelop/ the
updater would need root permissions (You aren't running X as root, now
are you?). This would mean either 1) the updater is a seperate app (not
desirable imo) or 2) You run MD as root to update (also not desirable).

There are potential ways to workaround this, like allowing
~/.config/MonoDevelop/AddIns/ to be added to the AddIn tree so that
newer versions there would supercede installed versions, but then you
get into yet another updating concern, what happens when you have 0.3
installed, put some 0.4 pieces into your ~/.config/ addin tree, then do
a system upgrade to 0.5... the old pieces in the ~/.config/ tree would
supercede and screw you.

basically any proposal to add in-app updating would have to provide a
good way to handle that. It would also have to explain why this
functionality is desired(/required). I can see its use in something like
eclipse, which has a lot of third-party plugins, but right now, we don't
have that issue.

--Todd

> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list