Revision as of 10:43, 30 January 2011

ModelView framework in Marble

Marble uses Qt's Model/View framework as a way to signal updates to a model to interested parts. In that respect, a Model class can wrap any possible data.

The Model-View framework is designed to hide the details of the model content, and to present it in a standardised way to views. The advantage of this solution is that the View need not know much about the data it presents.

The multiple models and proxies in Marble each fit the purpose of feeding some GeoData classes to interested widgets. Those models are fed by the FileManager.

Here is the list of Model and Proxy classes, and a description of how they are used.

GeoDataTreeModel

The GeoDataTreeModel represents the list of all GeoDataDocument registered through the FileManager.

It has signals/slots to react to files being added or removed in the FileManager.

It is used as the base model for GeoDataDocuments.

The GeometryLayer renders all GeoDataGeometry related placemarks.

FileViewModel

The FileViewModel represents the list of opened files. The FileManager appends the documents it opens. It is used by the FileViewFloatItem.

KDescendantsProxyModel

The KDescendantsProxyModel is used to flatten the tree of GeoData features. It represents the list of all Placemarks of all opened files.

The MarbleControlBox uses that proxy model to provide the list of placemarks to search for, and the PlacemarkLayout uses it also to determine layouting on the map.

@@ Line 3: / Line 3: @@
 Marble uses Qt's Model/View framework as a way to signal updates to a model to interested parts. In that respect, a Model class can wrap any possible data.
-The multiple models in Marble each fit the purpose of feeding some GeoData classes to interested widgets. The way those models are fed could be improved however:
+The Model-View framework is designed to hide the details of the model content, and to present it in a standardised way to views. The advantage of this solution is that the View need not know much about the data it presents.
-== Model and Data Location ==
+The multiple models and proxies in Marble each fit the purpose of feeding some GeoData classes to interested widgets. Those models are fed by the {{class|FileManager|kdeedu|4.x}}.
-* At the moment, each Model contains the list/vector/tree of data it presents. This is not a problem per se, unless all those models present the same data, and retain their own copies. We should ensure that we do not make copies of data throughout models, but use pointers to the same data instead.
+Here is the list of Model and Proxy classes, and a description of how they are used.
-The solution to this is twofold:
+=== GeoDataTreeModel ===
-** keep data unique in one store (wherever that is, a Model class or a list in one Manager)
+The {{class|GeoDataTreeModel|kdeedu|4.x}} represents the list of all {{class|GeoDataDocument|kdeedu|4.x}} registered through the {{class|FileManager|kdeedu|4.x}}.
-** Try and manipulate references to the data in the Models in such a case: with one change to the central data, multiple models can be notified and each react differently for the views they feed.
-== Model or not Model ==
-* The Model-View framework is designed to hide the details of the model content, and to present it in a standardised way to views. The advantage of this solution is that the View need not know much about the data it presents.
-This solution however is not a one size fit all, because an interested class with some knowledge of the GeoDataTypes for example would be far better off manipulating the methods of GeoData classes.
-As a consequence, a choice should be made whether to access GeoData through the model-view framework (nice for a List Widget or for a generic presentation of 'data as a tree', really not so nice for a class which for example would like to calculate the bounding box of all geometric data of a GeoDataDocument, or even for the File read/write, as the knowledge of data types is really known).
-== State of the Model ==
-There are multiple models with various levels of implementation. Some are needed, others should die...
-Here is the list of Model class, and a description of how they are used.
-=== QAbstractItemModel ===
-* {{class|GeoDataTreeModel|kdeedu|4.x}}
-It represents the list of all {{class|GeoDataDocument|kdeedu|4.x}} registered through the {{class|FileManager|kdeedu|4.x}}.
 It has signals/slots to react to files being added or removed in the FileManager.
-It is used by the {{class|GeometryLayer|kdeedu|4.x}} which renders all {{class|GeoDataGeometry|kdeedu|4.x}} related placemarks.
+It is used as the base model for GeoDataDocuments.
-* {{class|GeoDataDebugModel|kdeedu|4.x}}
-It represents a data file, parsed into a {{class|GeoDataDocument|kdeedu|4.x}} tree structure.
-It is used by the {{class|DataViewPlugin|kdeedu|4.x}} debug plugin (and is broken atm)
-=== QAbstractListModel ===
-* {{class|FileViewModel|kdeedu|4.x}}
-It represents the list of opened files. The {{class|FileManager|kdeedu|4.x}} appends the documents it opens.
-It is used by the {{class|FileViewFloatItem|kdeedu|4.x}} and manipulated by the {{class|FileManager|kdeedu|4.x}}.
+The {{class|GeometryLayer|kdeedu|4.x}} renders all {{class|GeoDataGeometry|kdeedu|4.x}} related placemarks.
-* {{class|MarblePlacemarkModel|kdeedu|4.x}}
+=== FileViewModel ===
-It represents the list of all Placemarks of all opened files. the {{class|PlaceMarkManager|kdeedu|4.x}} appends all the placemarks after reading a file.
+The {{class|FileViewModel|kdeedu|4.x}} represents the list of opened files. The {{class|FileManager|kdeedu|4.x}} appends the documents it opens.
+It is used by the {{class|FileViewFloatItem|kdeedu|4.x}}.
-It is used by the {{class|MarbleControlBox|kdeedu|4.X}} to provide the list of placemarks to search for, and by the {{class|PlacemarkLayout|kdeedu|4.x}} to determine layouting on the map.
+=== KDescendantsProxyModel ===
+The {{class|KDescendantsProxyModel|kdeedu|4.x}} is used to flatten the tree of GeoData features. It represents the list of all Placemarks of all opened files.
-It should be replaced by a more generic model, which would hold all open documents and provide both features and geometries. It could also be replaced with a ProxyModel around this new model.
+The {{class|MarbleControlBox|kdeedu|4.X}} uses that proxy model to provide the list of placemarks to search for, and the {{class|PlacemarkLayout|kdeedu|4.x}} uses it also to determine layouting on the map.