[MonoDevelop] Assembly reorganization

[Lluis Sanchez]

Inline:

> > The basic idea is to split the API in (at least) three assemblies:
> > 
> >       * MonoDevelop.Core: it would be the core runtime of MD. It would
> >         contain what it has right now plus some services moved from
> >         MonoDevelop.Base. It would not contain anything related to the
> >         GUI.
> >       * MonoDevelop.Gui: This assembly would contain user interface
> >         components for displaying, browsing or managing the information
> >         from the MD runtime, together with other utility classes.
> >       * MonoDevelop.IdeApplication: This would implement the MonoDevelop
> >         IDE, based on the previous assemblies.
> 
> Not quite sure of the value of having the last two separated.
> MonoDevelop.Gui would expose components that plugins could use and
> IdeApplication would be only for top-level non-reusable logic?

Well, more or less. However, not only addins are going to reuse
MonoDevelop.Gui. There can be other standalone applications based on the
MD runtime and GUI components, but with no relation to the IDE.

> From
> the line-up bellow it doesn't quite look so.
> 
> Also I disliked the IdeApplication name, I would prefer just
> MonoDevelop.Application.

I also don't like IdeApplication too much as well. However, I don't
think that MonoDevelop.Application is also good enough since, as I said,
there can be other MD based applications in the future. The namespace
should differentiate the IDE application from other applications.


> >       * MonoDevelop.Core.Parser
> >               * Parser classes.
> >       * MonoDevelop.Core.Projects
> >               * Everything from MonoDevelop.Internal.Project (which
> >                 includes Combine, CombineEntry, Project, IFileFormat and
> >                 related classes).
> 
> Here we need to define if we will continue to call super-projects as
> 'Combine's or 'Solution's (some parts of the UI uses, and the new
> extension for the default file [.mds] imply, Solution), And be
> consistent, unless that messes things with the common code still being
> shared with SharpDevelop. I personally prefer 'Solution'.

Yeah, I agree.

> 
> >       * MonoDevelop.Core.Serialization
> >               * Everything from MonoDevelop.Internal.Serialization.
> >       * MonoDevelop.Core.ProgressMonitoring
> >               * IProgressMonitor and support classes.
> > 
> > This assembly would not contain anything related to the GUI. It would
> > have the minimal runtime you need to use MD features. For example,
> > implementing a command line tool for building MD projects should be as
> > easy as:
> > 
> > public static void Main (string[] args)
> > {
> >   Runtime.Initialize ();
> >   Project project = (Project) Runtime.ProjectService.ReadFile (args
> > [0]);
> >   project.Build (new ConsoleProgressMonitor ());
> > }
> > 
> > > mcs builder.cs /r:MonoDevelop.Core
> > 
> > 
> > MonoDevelop.Gui.dll
> > -------------------
> > 
> >       * MonoDevelop.Gui
> >               * The DispatchService, which should probably be changed to
> >                 a helper static class, instead of a service.
> >               * MessageService.
> >               * Management of stock icons and resources.
> >       * MonoDevelop.Gui.Completion
> >               * Code completion window.
> >       * MonoDevelop.Gui.Content
> >               * Content interfaces (IEditable, IPositionable,
> >                 IParsableContent, etc.)
> >       * MonoDevelop.Gui.Dialogs
> >               * Option dialogs and panels for Project and Combine.
> >               * Other dialogs.
> > 
> > This could be an example of usage, which would display the options
> > dialog of a project:
> > 
> > public static void Main (string[] args)
> > {
> >   Runtime.Initialize ();
> >   Project project = (Project) Runtime.ProjectService.ReadFile (args
> > [0]);
> >   if (ProjectDialogs.ShowOptionsDialog (project))
> >      project.Save ();
> > }
> > 
> > MonoDevelop.IdeApplication.dll
> > ------------------------------
> > 
> >       * MonoDevelop.IdeApplication
> >               * The Ide class: a root class for accessing all IDE
> >                 services (like we have Runtime for the core services).
> 
> As I said I prefer MonoDevelop.Application.
> 
> >       * MonoDevelop.IdeApplication.Gui
> >               * Everything related to IWorkbench, IWorkbenchLayout, pads
> >                 and views.
> >               * Status bar and toolbar.
> >       * MonoDevelop.IdeApplication.Gui.Pads:
> >               * The main pads: project pad, class pad, task pad, file
> >                 pad, etc.
> >       * MonoDevelop.IdeApplication.Gui.Search:
> >               * The search GUI.
> >       * MonoDevelop.IdeApplication.Commands:
> >               * Implementation commands and command IDs.
> >       * MonoDevelop.IdeApplication.Services:
> >               * The CommandService
> >               * Management of external tools.
> >               * The Parser Service.
> >               * MonodocService (maybe rename to HelpService?)
> 
> Yeah, HelpService or DocumentationService are better than MonodocService.
> 
> > I'm not using MonoDevelop.Gui.Ide as assembly name because it would
> > conflict with the Ide class. Other name proposals (for this and other
> > assemblies and namespaces) are welcome.
> > 
> > Other assemblies
> > ----------------
> >       * MonoDevelop.Startup: no changes.
> >       * ICSharpCode.SharpAssembly: no changes.
> >       * ICSharpCode.SharpRefactory: no changes.
> >       * MonoDevelop.Base: removed.
> >       * MonoDevelop.Dock: No changes.
> >       * MonoDevelop.Gui.Utils: It's very small. Maybe it could be marged
> >         with another assembly (MonoDevelop.Gui?)
> >       * MonoDevelop.Gui.Widgets: no changes.
> > 
> > 
> > Please, comment on this.
> > Thanks!
> > Lluis.
> 
> I've presented my first-review comments, may find something else to
> add later, but probably not.
> 
> Fun,
> 

Thanks for the comments!
Lluis