[MonoDevelop] More on assembly reorganization

[Lluis Sanchez]

Hi,

I've been doing some reorganization work, and I now have the first draft
of the new structure. There are two main goals in this reorganization:

     1. to separate GUI classes from non-GUI classes, so it is possible
        to implement command line tools which don't have any gnome or
        GTK dependency. 
     2. to separate IDE-specific code from code which is not
        IDE-specific, to make it possible to write some kind of tools
        which don't need the full IDE to be installed.

Taking into account this goals, I came up with the following assemblies:

      * MonoDevelop.Core: The core runtime, which basically provides the
        AddIn engine, and some basic services.
      * MonoDevelop.Core.Gui: Basic GUI services, such as the
      * DispatchService, MessageService. Depends on MonoDevelop.Core. 
      * MonoDevelop.Projects: Everything related to Combine, Project,
        language bindings, and so on. Depends on MonoDevelop.Core. 
      * MonoDevelop.Projects.Gui: Some GUI classes for displaying
      * project related information. Depends on MonoDevelop.Projects,
        and MonoDevelop.Core.*. 
      * MonoDevelop.Components: Reusable components. 
      * MonoDevelop.Ide: The MonoDevelop Ide. Depends on the other
        assemblies.

I'm attaching the list of namespaces and classes that belong to each
assembly. Click on the namespace name to expand the class list. Only
public API is included.

There are some additions to the API that are worth commenting. There are
three new important classes in MonoDevelop.Ide.Gui: Workbench, Pad and
Document. Those classes basically wrap the IWorkbench, IPadContent and
IViewContent interfaces, and provide extra functionality which is IDE
specific. For example, the Document.Save method will show the Save As
dialog if the file is new, and will create a backup copy of the file if
that IDE option is set. IViewContent.Save just saves the content.

Notice that IWorkbench, IWorkbenchLayout, IWorkbenchWindow and other
related interfaces don't appear in the namespace list because they are
now internal. From now on, we should be very conservative about what we
put in the public MD API. If we make a component private, we can always
make it public in future MD versions without breaking the API, but if we
make a component public from the beginning, we'll need to carry with it
forever (or until we decide to break the api).

The directory structure will also change. We'll use the same structure
as in Mono, where there is a directory for each namespace.

Comments?
Lluis.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodevelop-list/attachments/20050826/70a6ff5b/namespaceModel.html