Marble/GraphicsViewGeoParser: Difference between revisions

Revision as of 17:56, 8 September 2009

The Problem

Data is read from files with the GeoDataParser framework in order to be displayed.

The GeoData framework is used to manipulate GeoDataObject classes. GeoData should be accessed in a sensible way because of its "shared data" logic.

Items to be displayed are GeoGraphicsItems, following the GeoGraphicsView framework.

The Link between GeoData and GeoGraphicsItems has to permit:

To display corresponding items, and get the data updates.
To possibly edit data through interaction (i.e. clicking on the map, dragging an item...)

A bit of history and issues

GeoData manipulation

Previously, GeoData has been accessed through shallow copy from the rendering objects. this posed problems as GeoData uses data sharing internally and updates in GeoData were thus not seen in Items.

Model-View framework

Also, the Model-View framework from Qt has been used many times with various shades of success for that specific matter (see Model View status for more info).

A "Model" in the Model-view framework in Qt is an interface to facilitate access to lists of data from widgets which need not know what data is inside. The interface may sound nice, but the abstraction is a bit too much when the interaction between data and its representation increases. These "Model" are also not data stores in order to avoid the previous issue.

Multiple Inheritance try

Multiple inheritance could be possible 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. We also try not to have multiple inheritance at all so...

Possible Solutions and discussion

Display the data

We should follow an Observer Pattern logic for the first goal whereas GeoGraphicsItems would observe the GeoData.

Multiple options are available for an observer pattern implementation:

use signal/slots (after all, this is one of Qt's best success)
implement light event handling methods (like java event listener classes)
use qt's model-view framework of model-view-ng (more info needed to see if it fits the observer solution)

Edit the data

We should think carefully about storing data to provide the second goal, so that editing is done in the GeoData and then updates happen in GeoGraphicsItems as a result.

@@ Line 1: / Line 1: @@
-== GeoParser and the GeoGraphicsView ==
+== The Problem ==
-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.
+Data is read from files with the [[Projects/Marble/GeoData/GeoDataParsing|GeoDataParser framework]] in order to be displayed.
-=== Casting ===
+The [[Projects/Marble/GeoData|GeoData framework]] is used to manipulate {{class|GeoDataObject|kdeedu|4.x}} classes. GeoData should be accessed in a sensible way because of its "shared data" logic.
-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 ===
+Items to be displayed are {{class|GeoGraphicsItems|kdeedu|4.x}}, following the [[Projects/Marble/GeoGraphicsViewOverview|GeoGraphicsView]] framework.
-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 Link between GeoData and GeoGraphicsItems has to permit:
+* To display corresponding items, and get the data updates.
+* To possibly edit data through interaction (i.e. clicking on the map, dragging an item...)
-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:
+== A bit of history and issues ==
-* use signal/slots
+=== GeoData manipulation ===
-* implement light event handling methods
+Previously, GeoData has been accessed through shallow copy from the rendering objects. this posed problems as GeoData uses data sharing internally and updates in GeoData were thus not seen in Items.
-* use qt's model-view framework of model-view-ng
+=== Model-View framework ===
+Also, the Model-View framework from Qt has been used many times with various shades of success for that specific matter (see [[Projects/Marble/ModelView|Model View status]] for more info).
+A "Model" in the Model-view framework in Qt is an interface to facilitate access to lists of data from widgets which need not know what data is inside. The interface may sound nice, but the abstraction is a bit too much when the interaction between data and its representation increases. These "Model" are also not data stores in order to avoid the previous issue.
+=== Multiple Inheritance try ===
+Multiple inheritance could be possible 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. We also try not to have multiple inheritance at all so...
+== Possible Solutions and discussion ==
+=== Display the data ===
+We should follow an [http://en.wikipedia.org/wiki/Observer_pattern Observer Pattern] logic for the first goal whereas GeoGraphicsItems would observe the GeoData.
+Multiple options are available for an observer pattern implementation:
+* use signal/slots (after all, this is one of Qt's best success)
+* implement light event handling methods (like java event listener classes)
+* use qt's model-view framework of model-view-ng (more info needed to see if it fits the observer solution)
+=== Edit the data ===
+We should think carefully about storing data to provide the second goal, so that editing is done in the GeoData and then updates happen in GeoGraphicsItems as a result.