Projects/Marble/GeoGraphicsViewOverview - Revision history

Bholst at 16:49, 31 March 2010

2010-03-31T16:49:09Z

Bholst at 21:56, 29 March 2010

2010-03-29T21:56:45Z

Bholst: some thoughts about Screen and GeoItems ...

2010-03-29T21:50:30Z

some thoughts about Screen and GeoItems ...

Tampakrap: link mentioned classes to their API documentation, small clarifications

2009-09-04T11:09:18Z

link mentioned classes to their API documentation, small clarifications

Tampakrap: GeoGraphicsView update by tackat

2009-07-10T12:35:28Z

GeoGraphicsView update by tackat

Unormal: Typos

2009-07-09T12:32:27Z

Typos

Mansona: moved GeoGraphicsViewOverview to Projects/Marble/GeoGraphicsViewOverview: Make it a sub item of Marble

2009-07-09T10:31:05Z

moved GeoGraphicsViewOverview to Projects/Marble/GeoGraphicsViewOverview: Make it a sub item of Marble

Mansona: Created page with '== GeoGraphicsView Overview == We are currently working on an implementation of a GeoGraphicsView system, which is intended to be very closely modeled on the QGraphicsView class...'

2009-07-09T10:27:07Z

Created page with '== GeoGraphicsView Overview == We are currently working on an implementation of a GeoGraphicsView system, which is intended to be very closely modeled on the QGraphicsView class...'

New page

== 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 QGrahpicsView 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 [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 ).

← Older revision		Revision as of 16:49, 31 March 2010
Line 37:		Line 37:
	The ScreenGraphicsItems could be managed in a ScreenGraphicsScene. Perhaps it is possible to use a QGraphicsScene for this.		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.		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.

@@ Line 32: / Line 32: @@
 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 on top of any MarbleGraphicsItem with a position relative to the position of the parent item.
+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.

← Older revision		Revision as of 21:50, 29 March 2010
Line 27:		Line 27:

	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.		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.
		+
		+	=== About GeoGraphicsItems and SceneGraphicsItems ===
		+
		+	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 on top 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.

@@ Line 1: / Line 1: @@
 == GeoGraphicsView Overview ==
-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
+GeoGraphicsView is one of the central parts of the Marble API. Built on top of [http://api.kde.org/4.x-api/kdeedu-apidocs/marble/html/classMarble_1_1GeoPainter.html GeoPainter], it allows the user to interact with objects in a way that
 * provides items that are arranged and can be accessed in a scene-graph.
-* provides an API and design that is closely modelled after QGraphicsView.
+* provides an API and design that is closely modelled after [http://doc.trolltech.com/4.5/qgraphicsview.html QGraphicsView].
 * has got a Qt Style API so that Qt developers get up to speed quickly.
 * has got a KML Style API so that people with GIS knowledge are quickly able to use it.
@@ Line 22: / Line 22: @@
 * The QGraphicsView API relies on QPainter, while we need to use the GeoPainter for the GeoGraphicsView.
 * The positions inside QGraphicsView get stored as members which is error prone as this can easily result in severe position synchronisation problems.
-* The BspTree inside QGraphicsView is pixel based (2 coordinates) while we need a lat-lon-alt BspTree.
+* The [http://en.wikipedia.org/wiki/Binary_space_partitioning BspTree] inside QGraphicsView is pixel based (2 coordinates) while we need a lat-lon-alt BspTree.
 * Some projections map a single lat-lon-alt coordinate to several pixel positions. This is not possible in QGraphicsView.
@@ Line 31: / Line 31: @@
 === Some 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 Qt Graphics View Framework are:
 * Simplified input event model
-* QGraphicsItems "know" how to draw themselves
+* [http://doc.trolltech.com/4.5/qgraphicsview.html 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 [http://doc.qtsoftware.com/4.5/graphicsview.html Qt Documentation]
+If you are not familiar with the Qt Graphics View Framework check out its [http://doc.qtsoftware.com/4.5/graphicsview.html 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 ).
+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 [http://api.kde.org/4.x-api/kdeedu-apidocs/marble/html/classMarble_1_1GeoParser.html GeoParser] to the [http://api.kde.org/4.x-api/kdeedu-apidocs/marble/html/classMarble_1_1MarbleGeoDataModel.html model]).

@@ Line 1: / Line 1: @@
 == 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.
+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
-=== Benefits of QGraphicsView for marble ===
+* provides items that are arranged and can be accessed in a scene-graph.
 Some of the main benefits that we would like to take advantage of from the QGraphicsView classes are: