| | 1 | = Maestro 3.0 UI Changes = |
| | 2 | |
| | 3 | In one word: everything. |
| | 4 | |
| | 5 | The UI design of Maestro 3.0 is intended to mirror that of [http://fdotoolbox.googlecode.com] |
| | 6 | |
| | 7 | == Foundations == |
| | 8 | |
| | 9 | The foundation of Maestro 3.0 is [http://www.sharpdevelop.net SharpDevelop Core]. SharpDevelop Core provides us the following: |
| | 10 | |
| | 11 | * An addin architecture allowing for extensibility and dynamic composition of components. |
| | 12 | * Dynamic/extensible menus, context menus and toolbars |
| | 13 | * Logging |
| | 14 | * Storage of User Preferences |
| | 15 | * Unified messaging |
| | 16 | * Lots of UI helper/utility classes |
| | 17 | |
| | 18 | 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. |
| | 19 | |
| | 20 | We use the latest SharpDevelop Core from the 3.x series and 4.x is WPF based. This has been tested and verified to be working in Mono. |
| | 21 | |
| | 22 | == Editor Architeture == |
| | 23 | |
| | 24 | Most editors are now rebuilt to maximize the use of databinding and the [http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged.aspx interface]. All of the xsd generated classes implement INotifyPropertyChanged. |
| | 25 | |
| | 26 | 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 occurence. |
| | 27 | |
| | 28 | == Versioning == |
| | 29 | |
| | 30 | 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 only 2 types of resources have various versions: |
| | 31 | |
| | 32 | * Layer Definitions |
| | 33 | * Load Procedure |
| | 34 | |
| | 35 | And each new version incrementally builds on previous versions. The editor UIs as a result can follow the same pattern. |
| | 36 | |
| | 37 | 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 new er 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. |
| | 38 | |
| | 39 | 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. |
