= Maestro 3.0 UI Changes =

In one word: everything. 

The UI architecture of Maestro 3.0 is intended to mirror that of [http://fdotoolbox.googlecode.com FDO Toolbox]. Flexible and extensible.

== Foundations ==

The foundation of Maestro 3.0 is [http://www.sharpdevelop.net SharpDevelop Core]. SharpDevelop Core provides us the following:

 * An addin architecture allowing for extensibility and dynamic composition of components.
 * Dynamic/extensible menus, context menus and toolbars
 * Logging
 * Storage of User Preferences
 * Unified messaging
 * Lots of UI helper/utility classes

Unlike FDO Toolbox however, we do not use [http://sourceforge.net/projects/dockpanelsuite/ DockPanel Suite] as our UI layout solution as that is not portable (the codebase uses lots of P/Invokes, thus windows only). Instead we are rolling our own UI layout solution, which involves a set of [http://msdn.microsoft.com/en-us/library/system.windows.forms.tabcontrol.aspx TabControl] components spread across 4 well defined zones (left, right, bottom and document). While not as flexible as DockPanel Suite, this solution runs in Mono which is one of the key criteria.

We use the latest SharpDevelop Core from the 3.x series as 4.x is WPF based. This has been tested and verified to be working in Mono.

== Editor Architeture ==

Most editors are now rebuilt to maximize the use of databinding and the [http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged.aspx INotifyPropertyChanged interface]. All of the xsd generated classes implement INotifyPropertyChanged.

The editor infrastructure uses INotifyPropertyChanged to automatically trigger dirty state notification for any editor. This approach is much easier and cleaner than the previous approach, which was to listen for UI events, update the internal model and signal dirty state. Databinding with INotifyPropertyChanged allows us to do all this in one shot (for most cases). Complex cases (such as UIs with grids) may require custom databinding logic, but this is a rare occurrence.

All editor components have access to the IEditorService interface. This interface provides a subset of the APIs IServerConnection interface and additional services for:

 * Browsing/Selecting Coordinate Systems
 * Editing Expressions
 * Resource/Folder selection
 * Resource dirty state management
 * Resource persistence

A default implementation of IEditorService is provided by the Maestro base addin.

== Versioning ==

Unlike MapGuide Studio, Maestro 3.0 will not silently upgrade resources when saving. Like previous versions, Maestro 3.0 will edit the resource in its current version. Unlike previous versions of Maestro however, Maestro 3.0 will attempt to support every known version of a given resource. Though this sounds like a lot of work, the reality is that only the following types of resources have various versions:

 * Layer Definitions
 * Load Procedure
 * Symbol Definitions
 * Web Layouts

And each new version incrementally builds on previous versions. The editor UIs as a result can follow the same pattern.

As already mentioned Maestro 3.0 will not silently upgrade your edited resources. What it does however is check if a given resource is upgradeable to a newer version. If this is the case, the editor UI will display a firefox-style notification indicating that the currently edited resource can be upgraded to a newer version. If the user chooses to upgrade, the existing resource is saved, upgraded and opened in a editor that supports the given resource version.

For versions that are not recognised by Maestro's resource editors (or resource types not recognised by Maestro), the XML editor is used as a fallback. The XML editor also has this upgrade checking capability