[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    KDE/kdeedu/marble
From:       Torsten Rahn <tackat () kde ! org>
Date:       2008-01-21 23:08:32
Message-ID: 1200956912.062076.19483.nullmailer () svn ! kde ! org
[Download RAW message or body]

SVN commit 764493 by rahn:


- More small adjustments



 M  +5 -0      TODO  
 M  +5 -4      docs/layermanagement.txt  


--- trunk/KDE/kdeedu/marble/TODO #764492:764493
@@ -39,6 +39,11 @@
     To get useful temperature/precipation/... maps we need to be able
     to add items to the legend in the .dgml file:
 
+    This is also a first step towards the new DGML version format that 
+    we need for the new layer management class.
+
+    see also: docs/layermanagement.txt.
+
 <Legend>
     <heading>Temperature</heading>
     <LegendItem>
--- trunk/KDE/kdeedu/marble/docs/layermanagement.txt #764492:764493
@@ -25,12 +25,13 @@
 	
 - "Execution order" of the different backends should be based on the \
following mechanisms:  a) each backend should provide "hardcoded" hints \
which describe dependencies (e.g. the texture colorization depends on the \
result of a texturemapping backend ) and allowed ranges for the rendering \
order (e.g. floating items should always be displayed on top of the map,  a \
                starry background needs to get drawn before the globe is \
                painted)
-	b) the layermanagement class needs to fetch information from the \
.dgml-parser about the different types of backends that get used in a map. \
The .dgml file also needs to provide information about the rendering order. \
+	b) In Marble the structure of each map gets described in the map's .dgml \
file. So the layermanagement class needs to fetch information from the \
.dgml-parser about the different types of backends that get used in a map. \
The .dgml file also needs to provide information about the rendering order. \
c) for backend types where there are no hard requirements on the rendering \
order the LMC should decide itself which order to take.  
-- According to the concept described so far it should be possible to paint \
different layers based on the very same backend  directly on top of each \
other (e.g. a cloud layer on top of a satellite map layer. This would \
result in two different layers. However for reasons of performance it needs \
                to be possible to merge the data into a single layer \
                ("MergedLayer"). 
-This gets already done for placemarks where data from different files gets \
merged into a single file. It also gets done already for clouds on top of \
the satellite image data. However what's missing is a more generic approach \
where a MergedLayerPainter class operates directly on the tiles based on \
the information it receives from the LMC. Before telling the \
MergedLayerPainter class which layers need to get painted on top of the \
tiles the LMC needs to check whether tiles or sourceimage data is available \
for the map. If there is no such data available the LMC needs to either \
notify the TileLoader that it needs to create tiles or the LMC will simply \
ignore the missing data and will skip asking the MergedLayerPainter to \
render the missing data.  +- According to the concept described so far it \
should be possible to paint different layers based on the very same backend \
directly on top of each other (e.g. a cloud layer on top of a satellite map \
layer. Normally this would result in two different layers. However for \
reasons of performance it needs to be possible to merge the data into a \
single layer right from the start("MergedLayer").  
+This gets already done for placemarks in current SVN where data from \
different files gets merged into a single file. It also gets done already \
for clouds on top of the satellite image data. However what's missing is a \
more generic approach where a MergedLayerPainter class operates directly on \
the tiles based on the information it receives from the LMC. Before telling \
the MergedLayerPainter class which layers need to get painted on top of the \
tiles the LMC needs to check whether tiles or sourceimage data is available \
for the map. If there is no such data available the LMC needs to either \
notify the TileLoader that it needs to create tiles or the LMC will simply \
ignore the missing data and will skip asking the MergedLayerPainter to \
render the missing data.  +
 - The plugin-backend concept should allow CUSTOM BACKENDS created by third \
                party developers. 
 - Creating new geographical features on the map should happen using a \
Qt-like API (which would include the QPainter API to draw in screen \
coordinates):  
@@ -47,7 +48,7 @@
 	painter.drawGeoEllipse( here.lon(), here.lat(), 5, 5 ); 
 	
 
-- It should be possible to use this Qt-like Geo-API either from outside \
the MarbleWidget or from inside the custom backend plugin. +- It should be \
possible to use this Qt-style Geo-API either from outside the MarbleWidget \
or from inside the custom backend plugin.  
 
 FUTURE low-priority enhancements (for usage in "real" light GIS apps that \
might use Marble in the future):


[prev in list] [next in list] [prev in thread] [next in thread]