GeoGraphicsView is one of the central parts of the Marble API. Built on top of GeoPainter, it allows the user to interact with objects in a way that
In opposite to QGraphicsView the GeoGraphicsView ...
As a result it's not feasible to use QGraphicsView directly to create the GeoGraphicsView for several reasons:
There has been talk with people from Qt Software about the issues above. Some of the differences can be reduced. Most differences however will remain due to the very different nature of the targeted use case. By reducing differences we can however make it easier for developers to learn and understand both systems. If QGraphicsView and GeoGraphicsView would reach a point where they are close enough to each other it could even be considered that GeoGraphicsView would reuse the QGraphicsView implementation internally. However right now this rather looks unlikely.
Marble knows two types of MarbleGraphicsItems: some items, the GeoGraphicsItems, have a position in geo coordinates, and others, the ScreenGraphicsItems, simply hover in front (or possibly behind) of the globe independant from the globes position.
An example of a GeoGraphicsItem is a placemark. An example of a ScreenGraphicsItem are the FloatItems like the small compass, which resides in the upper right corner of the MarbleWidget by default. By the way, to make it a littlebit more complicated (at least for us), ScreenGraphicsItems can be children of any MarbleGraphicsItem with a position relative to the position of the parent item.
It doesn't make sense to try to put both in the same scene. Managing the GeoGraphicsItems could be done in a GeoGraphicsScene. This would work exactly as described above. The ScreenGraphicsItems could be managed in a ScreenGraphicsScene. Perhaps it is possible to use a QGraphicsScene for this. All these Items should be rendered to the same view, the MarbleGraphicsView.
Using QGraphicsScene could lead to some problems, most of them are due to the fact that Qt developers probably don't expect that somebody messes in different ways in their code compared to what it was designed for. Perhaps it could be possible to switch between these two options.
Some of the main benefits that we would like to take advantage of from the Qt Graphics View Framework are:
The QGraphicsView input model integrates the passing of mouse events based on the position of the mouse event, passing mouse events down through a stack of items and the ability to have a standard implementation of Drag and Drop.
If you are not familiar with the Qt Graphics View Framework check out its documentation.
Also a problem with the current way things are done in marble is that we have adopted a QVariant style Typing system for the GeoData classes. This is very effective ( and very fast ) for the current implementation of marble but does not allow for extension of the system by 3rd party developers for things like plugins. If we adopt the QGraphicsItem system then we will be passing pointers to objects around which will adhere to the C++ Run-Time Typing System and will not lose any Class/Inheritance information when passed around the Marble system (e.g. passing from the GeoParser to the model).
KDE TechBase 