Marble/GeoGraphicsViewOverview: Difference between revisions
*>Mansona m (moved GeoGraphicsViewOverview to Projects/Marble/GeoGraphicsViewOverview: Make it a sub item of Marble) |
(Typos) |
||
| Line 3: | Line 3: | ||
We are currently working on an implementation of a GeoGraphicsView system, which is intended to be very closely modeled on the QGraphicsView classes. We have to work on this as an internal project due to the current limitations that are in the QGraphicsView classes that do not allow for the implementation of projections directly. There is talk about these problems being fixed for Qt 4.6 and so it is important to model our API for this system on the current Qt classes so that we can convert the system painlessly when Qt 4.6 is released. | We are currently working on an implementation of a GeoGraphicsView system, which is intended to be very closely modeled on the QGraphicsView classes. We have to work on this as an internal project due to the current limitations that are in the QGraphicsView classes that do not allow for the implementation of projections directly. There is talk about these problems being fixed for Qt 4.6 and so it is important to model our API for this system on the current Qt classes so that we can convert the system painlessly when Qt 4.6 is released. | ||
=== Benefits of | === Benefits of QGraphicsView for marble === | ||
Some of the main benefits that we would like to take advantage of from the QGraphicsView classes are: | Some of the main benefits that we would like to take advantage of from the QGraphicsView classes are: | ||
| Line 13: | Line 13: | ||
If you are not familiar with the system check out the [http://doc.qtsoftware.com/4.5/graphicsview.html Qt Documentation] | If you are not familiar with the system check out the [http://doc.qtsoftware.com/4.5/graphicsview.html Qt 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 | 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 Geo Parser to the model ). | ||
Revision as of 12:32, 9 July 2009
GeoGraphicsView Overview
We are currently working on an implementation of a GeoGraphicsView system, which is intended to be very closely modeled on the QGraphicsView classes. We have to work on this as an internal project due to the current limitations that are in the QGraphicsView classes that do not allow for the implementation of projections directly. There is talk about these problems being fixed for Qt 4.6 and so it is important to model our API for this system on the current Qt classes so that we can convert the system painlessly when Qt 4.6 is released.
Benefits of QGraphicsView for marble
Some of the main benefits that we would like to take advantage of from the QGraphicsView classes are:
- Simplified input event model
- QGraphicsItems "know" how to draw themselves
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 system check out the Qt 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 Geo Parser to the model ).