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.
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).