| 15 | | The Qt toolkit would be a nice foundation to base the optional GUI component of the MapGuide desktop SDK on. It is cross-platform, also written in C++, has a rich set of features and as of v4.5 (the current release) is licensed under the same terms as MapGuide itself (LGPL). |
| | 17 | * Common/CoordinateSystem |
| | 18 | * Common/Geometry |
| | 19 | * Common/Foundation |
| | 20 | * Common/MdfModel |
| | 21 | * Common/MdfParser |
| | 22 | * Common/MapGuideCommon |
| | 23 | * Common/PlatformBase |
| | 24 | * Common/Renderers |
| | 25 | * Common/Schema |
| | 26 | * Common/Stylization |
| | 27 | * Server/src/Gws/GwsCommon |
| | 28 | * Server/src/Gws/GwsQueryEngine |
| | 29 | * Server/src/Gws/GwsResource |
| | 30 | * Any 3rd party libs these projects depend on |
| | 31 | |
| | 32 | If we were to take the Geospatial Platform API in AutoCAD Map as an example, the desktop-specific components would be: |
| | 33 | |
| | 34 | * A desktop-based implementation of PlatformBase, that would mainly be providing desktop implementations of: |
| | 35 | * MgFeatureService |
| | 36 | * MgResourceService |
| | 37 | * MgMapBase |
| | 38 | * MgSelectionBase |
| | 39 | * other abstract classes(?) |
| | 40 | |
| | 41 | The MgResourceService implementation would have to use an alternative to Berkeley DBXML due to licensing issues. Possible alternatives for a MgResourceService backing store include: |
| | 42 | |
| | 43 | * [http://modis.ispras.ru/sedna/ Sedna XML DB] |
| | 44 | * SQLite ? |
| | 45 | * Native filesystem with some sort of MgResourceIdentifier <-> file path addressing scheme. |
| | 46 | |
| | 47 | In terms of handling the managed/unmanaged resources divide, a desktop-based MapGuide could use a Sedna/directory combination or just simply a series of directories (one for each alias + one special directory for managed resources) |
| | 48 | |
| | 49 | This may sound like a case of NIH, seeing as MapGuideCommmon already provides an implementation of PlatformBase. The problem is that MapGuideCommon's implementation of PlatformBase has all the server/ACE/dbxml dependencies that we don't want or need in a desktop context (obviously because the server is using this library). The reason MapGuideCommon would exist in the desktop SDK is so that a desktop-based MapGuide can interop with a MapGuide Server, as we are currently doing in the Web Tier. |
| | 50 | |
| | 51 | = MapGuide Server Integration = |
| | 52 | |
| | 53 | A desktop-based MapGuide should have some form of integration/compatibility with MapGuide Server. |
| | 54 | |
| | 55 | == API == |
| | 56 | |
| | 57 | On the API side of things, this implementation would have the same API parity as the AutoCAD Map Geospatial Platform API and have the same limitations: |
| | 58 | |
| | 59 | * No MgRenderingService |
| | 60 | * No MgMappingService |
| | 61 | * No MgDrawingService |
| | 62 | * No MgKmlService |
| | 63 | * No MapGuide Server specific APIs (eg. MgSite, MgSiteConnection) |
| | 64 | |
| | 65 | == Resource Compatibility == |
| | 66 | |
| | 67 | A desktop-based implementation should be able to support all of the required MapGuide resource types, with the exception of: |
| | 68 | |
| | 69 | * WebLayout |
| | 70 | * ApplicationDefinition |
| | 71 | * PrintLayout (since we're not implementing MgMappingService) |
| | 72 | * DrawingSource (if we want no DWF dependency) |
| | 73 | * SymbolLibrary (if we want no DWF dependency) |
| | 74 | |
| | 75 | Namely, because these are web-specific resources that have cannot really be translated into a desktop context. Every other resource type should be consumable in a desktop context. |
| | 76 | |
| | 77 | == Data == |
| | 78 | |
| | 79 | Since a desktop implementation would have to implement MgResourceService::ApplyPackage(), MGP packages would be easily reusable in a desktop context, only web-specific resources would be ignored/discarded when loaded into a desktop context. |
| | 80 | |
| | 81 | Ideally there should be some way to consume MapGuide server layers directly, and the easiest solution for that would be to implement a [http://themapguyde.blogspot.com/2009/11/why-not.html MapGuide FDO Provider]. That way MapGuide can function like a WFS/WMS server, but you get all the nice FDO metadata that may have been lost by going through WFS/WMS. A MapGuide FDO provider would allow for '''dead simple''' replication of MapGuide Feature Sources. |
| | 82 | |
| | 83 | = A desktop application framework = |
| | 84 | |
| | 85 | At this point we would have a MapGuide API that is totally functional in a desktop context, free of any server dependencies and/or idioms. The only thing missing is the application side of things. If we want users to be able to build desktop MapGuide applications with very little programming knowledge, then we would need a desktop-based equivalent to the WebLayout/ApplicationDefinition. |
| | 86 | |
| | 87 | This framework would have a library of pre-defined widgets, so that the out-of-the-box functionality matches your basic AJAX/Fusion viewer: |
| | 88 | |
| | 89 | * Legend (Layer Control) |
| | 90 | * Map Selector |
| | 91 | * Map Canvas |
| | 92 | * Mini-Map |
| | 93 | * Menu |
| | 94 | * Toolbar |
| | 95 | * Button |
| | 96 | * Split Button (Flyout) |
| | 97 | * Context Menu |
| | 98 | * Task Pane (Or some generic content container?) |
| | 99 | * Attribute Viewer |
| | 100 | * Scale Bar |
| | 101 | * Generic Search/Query (Maybe something like AutoCAD Map's Data Grid instead?) |
| | 102 | * Generic Theme |
| | 103 | * Generic Redline |
| | 104 | * Generic Buffer |
| | 105 | * Generic Measure |
| | 106 | * Help |
| | 107 | * About |
| | 108 | * Print |
| | 109 | * Others? |
| | 110 | |
| | 111 | And of course if you need custom functionality, just roll your own widgets. Now it would be impractical from a resource perspective to write all this stuff from the ground up, we should be basing this framework on a pre-existing library. |
| | 112 | |
| | 113 | That is where [http://qt.nokia.com Qt] comes in. Qt is a very popular framework for '''cross platform''' applications and has just about every possible feature that we would ever need to use. As of v4.5 (current version is 4.6) it is licensed under the LGPL, thus there is no licensing issues at all. Qt provides all the necessary building blocks for a widget-driven desktop application framework. |
| | 114 | |
| | 115 | Having to code C++ for custom widgets/functionality isn't fun, but Qt makes interop with other higher-level languages very easy. Thus API bindings in other languages is an easy task. |
