|
|
| (4 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| == The Problem ==
| | {{ Moved To Community }} |
| Data is read from files with the [[Projects/Marble/GeoData/GeoDataParsing|GeoDataParser framework]] in order to be displayed.
| |
| | |
| 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.
| |
| | |
| Items to be displayed are {{class|GeoGraphicsItems|kdeedu|4.x}}, following the [[Projects/Marble/GeoGraphicsViewOverview|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 [[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 ==
| |
| | |
| === Time of creation of GeoGraphicsItems ===
| |
| To display the GeoDataFeature- and GeoDataGeometry-objects we want to use GeoGraphicsItems on a global GeoGraphicsScene.
| |
| This leads to the problem when to create the GeoGraphicsItems for displaying on the scene:
| |
| * Creating the items as they were read.
| |
| ** This will probably be really slow as GeoGraphicsItems shouldn't be created in the thread which parses the file.
| |
| * Using a proxy concept: In another Thread runs a check for the GeoDataFeatures and GeoDataGeometries which entered the scene (because of moving around). This will probably go through a list of say 20000 entries, but, as it runs in a thread it won't stop the user interface from repainting. As the user interface repaints (in main thread), the GeoGraphicsItems for the new GeoData...-objects are created (we know which are needed because of our Proxy-Thread). Our MarbleGraphicsScene allows to add items temporary, removing them when they are out of the viewport for some time. Our MarbleGraphicsScene would hold about 200 entries, which can be access via a list or a [http://en.wikipedia.org/wiki/Binary_space_partitioning BSP-tree] (depending on which turns out to be more reasonable).
| |
| | |
| === 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.
| |
| | |
| For reference, [http://doc.trolltech.com/4.6-snapshot/animation-overview.html#animations-and-the-graphics-view-framework Qt4.6 snapshot doc] regarding animation proposes for GraphicsItems to inherit QObject to receive signals from animation framework.
| |
| | |
| A less obtrusive solution is possible with some intermediary QObject-derived class which would manipulate GeoGraphicsItems when GeoData updates.
| |
| | |
| | |
| * implement light event handling methods (like java event listener classes)
| |
| | |
| | |
| * use qt's model-view framework of itemviews-ng
| |
| More info needed to see if it fits the observer solution...
| |
| | |
| A first glance at [[http://labs.trolltech.com/docs/Projects/itemviews-ng/ ItemView-ng Project API]] shows not much radical change in the model interaction compared to previous itemview...
| |
| | |
| === 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.
| |
