|
|
| (8 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| == GeoParser and the GeoGraphicsView ==
| | {{ Moved To Community }} |
| The current GeoData XML Parser ( aka. GeoParser ) has been implemented to specifically deal with our current GeoData data structure. If you want to see a more complete documentation of the GeoData library you can see the [[Projects/Marble/GeoData|GeoData documentation]]. I will only describe the particular problem to the GeoGraphicsView implementation here.
| |
| | |
| === Casting ===
| |
| The unfortunate thing about the current implementation of the GeoParser is that when any item is added to the Collection Data Structure it is effectively cast as an {{class|GeoNode|kdeedu|4.2}} and removes any ability for 3rd party developers to add parsing capability to marble with functionality other than that which marble provides. This is an issue that needs more investigation to provide more flexibility.
| |
| | |
| === Link between GeoData and GeoGraphicsItems ===
| |
| Previously, GeoData has been accessed through pointers from the rendering objects. this poses problems as GeoData uses data sharing and updates in GeoData are thus not seen in Items.
| |
| | |
| It could be possible to do multiple inheritance where GeoGraphicsItems would also be GeoNodes, but that raises issues regarding modularity, because both the model and its representation would be in the same object.
| |
| | |
| The better solution would follow an [http://en.wikipedia.org/wiki/Observer_pattern observer pattern] logic whereas GeoGraphicsItems would react to GeoData. Multiple options are available:
| |
| * use signal/slots
| |
| * implement light event handling methods
| |
| * use qt's model-view framework of model-view-ng
| |
Latest revision as of 04:46, 26 October 2016
