[MonoDevelop] Assembly reorganization

Rafael Teixeira monoman at gmail.com
Mon Jul 25 14:36:11 EDT 2005


Inline

On 7/25/05, Lluis Sanchez <lluis at ximian.com> wrote:
> This is a proposal of reorganization of the MD assemblies. Hopefully,
> this would be the last big API change before MD 1.0. The goal of this
> change is to improve the modularization of the MD API, and provide a
> more coherent, easy to use and reusable API.
> 
> MD is not just another GTK# application. It provides a public API that
> addins and other applications can use and extend. When we release MD 1.0
> this API will be frozen and only incremental changes will be allowed
> until MD 2.0, which may take quite a lot of time. That's why we need to
> make sure that MD 1.0 API covers most of the usage scenarios of MD.

Yes, I completely agree. 

> 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? From
the line-up bellow it doesn't quite look so.

Also I disliked the IdeApplication name, I would prefer just
MonoDevelop.Application. The sole conflict would be with the Gtk
namespace that also has an Application object and is itself used in
MD. I grepped a little and found 22 already qualified uses and 2 not
qualified (patch follows):

Index: Core/src/AddIns/DebuggerAddIn/Visualizers/VisualizerDevelopmentHost.cs
===================================================================
--- Core/src/AddIns/DebuggerAddIn/Visualizers/VisualizerDevelopmentHost.cs
     (revision 2668)
+++ Core/src/AddIns/DebuggerAddIn/Visualizers/VisualizerDevelopmentHost.cs
     (working copy)
@@ -120,7 +120,7 @@

                        vis.Show (null, new HostObjectProvider
(objectToVisualize));

-                       Application.Quit ();
+                       Gtk.Application.Quit ();

                        return false;
                }
Index: Core/src/MonoDevelop.Startup/Dialogs/ExceptionBox.cs
===================================================================
--- Core/src/MonoDevelop.Startup/Dialogs/ExceptionBox.cs        (revision 2668)
+++ Core/src/MonoDevelop.Startup/Dialogs/ExceptionBox.cs        (working copy)
@@ -69,7 +69,7 @@
                void AbortButton_Clicked(object obj, EventArgs ea)
                {
                        CallButtonHandlers(DialogResult.Abort);
-                       Application.Quit();
+                       Gtk.Application.Quit();
                }

                void ContinueButton_Clicked(object sender, System.EventArgs e)


> Some namespaces should also be renamed. A basic rule we should follow is
> that namespaces implemented in an assembly should have the assembly name
> as prefix.
> 
> OK, so that's the structure of assemblies and namespaces I propose:
> 
> MonoDevelop.Core.dll
> --------------------
> 
>       * MonoDevelop.Core
>               * The Runtime object, which would provide access to all
>                 those services.
>       * MonoDevelop.Core.Addins
>               * All API needed to load and manage addins.
>               * Codons not related to GUI.
>       * MonoDevelop.Core.Services
>               * Basic infrastructure of services.
>               * The property Service
>               * Project service (removing everything GUI related).
>               * Task service.
>               * StringParserService
>               * Logging service.
>               * SystemAssemblyService.
>               * ProcessService
>               * FileService (removing everything GUI related).
>       * 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'.

>       * 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,

-- 
Rafael "Monoman" Teixeira
---------------------------------------
I'm trying to become a "Rosh Gadol" before my own eyes. 
See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment.
It hurts!


More information about the Monodevelop-list mailing list