Marble/ModelView: Difference between revisions

    From KDE TechBase
    No edit summary
    No edit summary
    Line 1: Line 1:
    == ModelView framework in Marble ==
    = ModelView framework in Marble =


    Marble uses Qt's Model/View framework as a way to signal updates in a model to interested parts. In that respect, a Model class can wrap any possible data.
    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.


    Here is the list of Model classes, and a description of how they are used.
    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:
     
    == Model and Data Location ==
     
    * 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. Once the time to edit this data comes, it is tedious or quite impossible to trace back all those copies.
     
    The solution to this is twofold:
    ** keep data unique in one store (wherever that is, a Model class or a list in one Manager)
    ** 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 ===
    === QAbstractItemModel ===
    * {{class|GeoDataDebugModel|kdeedu|4.x}}
    * {{class|GeoDataDebugModel|kdeedu|4.x}}
    It represents the tree of {{class|GeoDataObject|kdeedu|4.x}} elements corresponding to a {{class|GeoDataDocument|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).
    It is used by the {{class|DataViewPlugin|kdeedu|4.x}} debug plugin (and is broken atm)


    * {{class|GpxFileModel|kdeedu|4.x}}
    * {{class|GpxFileModel|kdeedu|4.x}}
    It represents a list of gpx data files represented as {{class|GpxFile|kdeedu|4.x}}
    It represents a list of gpx data file represented as {{class|GpxFile|kdeedu|4.x}}


    This was originally intended to but used as the model for the File List View ( which is accessible by running marble with --enableFileView ) but has since been replaced by the FileViewModel.
    This was originally intended to but used as the model for the File List View ( which is accessible by running marble with --enableFileView ) but has since been replaced by the FileViewModel.


    The model is used as a member in the GpsLayer to hold the list of gpx files as a collection class and is deprecated. This, along with the whole current GPX implementation, needs to be removed and updated to the current concepts in Marble. See [[Projects/Marble/GPXStatus|Gpx Status]]
    The model that is in the GpsLayer is currently only being used as a collection class and is deprecated. This, along with the whole current GPX implementation, needs to be removed and updated to the current concepts in Marble. See [[Projects/Marble/GPXStatus|Gpx Status]]


    * {{class|MarbleGeometryModel|kdeedu|4.x}}
    * {{class|MarbleGeometryModel|kdeedu|4.x}}
    It represents the {{class|GeoDataGeometry|kdeedu}} and the {{class|GeoDataFeature|kdeedu|4.x}} items of the last opened {{class|GeoDataDocument|kdeedu|4.x}}.
    It represents the {{class|GeoDataGeometry|kdeedu}} and the {{class|GeoDataFeature|kdeedu|4.x}} items of the last opened {{class|GeoDataDocument|kdeedu|4.x}}.


    It is used by the {{class|GeoRenderPlugin|kdeedu|4.x}} to access the list of vector data and draw it.
    It is used by the {{class|GeoRenderPlugin|kdeedu|4.x}} to access the list of vector data to draw it.


    === QAbstractListModel ===
    === QAbstractListModel ===
    * {{class|FileViewModel|kdeedu|4.x}}
    * {{class|FileViewModel|kdeedu|4.x}}
    It represents the list of opened files. The {{class|FileManager|kdeedu|4.x}} signals it about the documents it opens or closes.
    It represents the list of opened files. The {{class|PlacemarkManager|kdeedu|4.x}} appends the documents it opens, and the {{class|MarbleWidget|kdeedu}} appends the gpx files it opens.


    It is used by the {{class|FileViewFloatItem|kdeedu|4.x}} and by a List widget in the {{class|MarbleControlBox|kdeedu|4.X}}.
    It is used by the {{class|FileViewFloatItem|kdeedu|4.x}} and manipulated by the {{class|PlaceMarkManager|kdeedu|4.x}} and the {{class|MarbleModel|kdeedu|4.x}}.


    * {{class|MarbleGeoDataModel|kdeedu|4.x}}
    * {{class|MarbleGeoDataModel|kdeedu|4.x}}
    It represents a list of {{class|GeoDataDocuments|kdeedu|4.x}}. Only the {{class|PlacemarksPlugin|kdeedu|4.x}} uses it.
    It represents a list of {{class|GeoDataDocuments|kdeedu|4.x}}. Only the {{class|PlacemarksPlugin|kdeedu|4.x}} uses it


    It is used by no other code.
    It is used by no other code.


    * {{class|MarblePlacemarkModel|kdeedu|4.x}}
    * {{class|MarblePlacemarkModel|kdeedu|4.x}}
    It represents a list of Placemarks.
    It represents the list of all Placemarks of all opened kml files. the {{class|PlaceMarkManager|kdeedu|4.x}} appends all the placemarks after reading a file.
     
    The {{class|PlaceMarkManager|kdeedu|4.x}} appends all the placemarks contained in the {{class|GeoDataDocument|kdeedu|4.x}} it knows about in its instance.
     
    The {{class|MarbleRunnerManager|kdeedu|4.x}} appends the list of placemarks that the Runners found in its instance.
     
    It is used by the {{class|MarbleControlBox|kdeedu|4.X}} to provide a list of placemarks (either from the PlacemarkManager or from the MarbleRunnerManager).


    It is also used by the {{class|PlacemarkLayout|kdeedu|4.x}} to determine layouting on the map.
    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.

    Revision as of 17:55, 14 September 2009

    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 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:

    Model and Data Location

    • 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. Once the time to edit this data comes, it is tedious or quite impossible to trace back all those copies.

    The solution to this is twofold:

      • keep data unique in one store (wherever that is, a Model class or a list in one Manager)
      • 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

    • Expression error: Unrecognized word "x".

    It represents a data file, parsed into a Expression error: Unrecognized word "x". tree structure.

    It is used by the Expression error: Unrecognized word "x". debug plugin (and is broken atm)

    • Expression error: Unrecognized word "x".

    It represents a list of gpx data file represented as Expression error: Unrecognized word "x".

    This was originally intended to but used as the model for the File List View ( which is accessible by running marble with --enableFileView ) but has since been replaced by the FileViewModel.

    The model that is in the GpsLayer is currently only being used as a collection class and is deprecated. This, along with the whole current GPX implementation, needs to be removed and updated to the current concepts in Marble. See Gpx Status

    • Expression error: Unrecognized word "x".

    It represents the GeoDataGeometry and the Expression error: Unrecognized word "x". items of the last opened Expression error: Unrecognized word "x"..

    It is used by the Expression error: Unrecognized word "x". to access the list of vector data to draw it.

    QAbstractListModel

    • Expression error: Unrecognized word "x".

    It represents the list of opened files. The Expression error: Unrecognized word "x". appends the documents it opens, and the MarbleWidget appends the gpx files it opens.

    It is used by the Expression error: Unrecognized word "x". and manipulated by the Expression error: Unrecognized word "x". and the Expression error: Unrecognized word "x"..

    • Expression error: Unrecognized word "x".

    It represents a list of Expression error: Unrecognized word "x".. Only the Expression error: Unrecognized word "x". uses it

    It is used by no other code.

    • Expression error: Unrecognized word "x".

    It represents the list of all Placemarks of all opened kml files. the Expression error: Unrecognized word "x". appends all the placemarks after reading a file.

    It is used by the Expression error: Unrecognized word "x". to provide the list of placemarks to search for, and by the Expression error: Unrecognized word "x". to determine layouting on the map.