Marble/GeoGraphicsViewOverview: Difference between revisions

From KDE Community Wiki
*>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 QGrahpicsView for marble ===
=== 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 loose any Class/Inheritance information when passed around the Marble system ( e.g. passing from the Geo Parser to the model ).
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 ).